„  FY79frinal  depart.  F¥  l1?^  . 

CabieBus  Applications  in  Command  CentersTj 

'*  '■  ~  ~T  -  ■-  — - ->~J 


S' 

10 


Steven  F.jHolmgren 
Anita  P.}Skelton 
David  A.jGomberg 


v 


Sponsor:  Defense  Communications  Agency/ 

Command  and  Coolxo^Technical  Center 


I’-JLtxrrasli  i  hi  II  III— 

#Ttas  riAn)cciW{tprovct! Wr  pubW'fficasc.  '  1 


The  MITRE  Corporation 
MITRE  C-’  Division 
Washington  C1  Operations 
1820  Dolley  Madison  Boulevard 
Mcl.ean,  Virginia  22102  I 


-  -  '..-'j 

Ar;.t  'S-  <1  or 


/ 


EXECUTIVE  SUMMARY 


.3  i 

t-j 


Microprocessor  technology  has  advanced  to  the  extent  that  the 
three  or  four  lowest  layers  of  a  typical  long-haul  network  protocol 
architecture  may  be  implemented  on  one  microprocessor-based  circuit 
board.  Hie  impact  of  this  evolutionary  step  on  the  capabilities  of 
microprocessor-based  networks  will  be  profound. 

This  report  documents  the  FY  79  activities  of  a  MITRE/DCA  pro¬ 
gram  to  determine  the  applicability  of  such  a  futuristic 
microprocessor-based  cable  bus  local  area  network  to  World  wide  Mil¬ 
itary  Command  and  Control  System  (WWMCCS)  command  centers.  Hie  major 
emphasis  of  this  program  has  been  on  a  comparative  analysis  of  cable 
bus  and  message  switch  local  area  network  architectures.  Potential 
cable  bus  and  message  switch  command  center  applicability  is  measured 
here  in  terms  of  security,  functionality,  reliability,  cost,  flexi¬ 
bility  and  performance. 

Specific  tasks  during  FY  79  included  the  installation  of  a  cable 
bus  test  bed  with  a  gateway  to  the  ARPA  network,  measurement  of  cable 
bus  performance,  and  partial  inplementation  of  a  cable  bus  protocol 
architecture. . 


Prototypes  of  the  message  switch  and  cable  bus  which  support 
WWMCCS  requirements  were  not  available  for  direct  measurement.  In 
fact,  further  research  and  experimentation  with  both  systems  is 
necessary  before  absolute  comparisons  can  take  place.  Thus  it  is 
felt  that  some  comparisons,  particularly  cost,  performance,  and  reli¬ 
ability  are  premature  enough  so  that  no  definitive  opinion  on  appli¬ 
cability  of  the  cable  bus  to  WWMCCS  command  centers  should  be  ren¬ 
dered  at  this  time. 

The  following  is  a  brief  summary  of  the  cable  bus  and  the  mes¬ 
sage  switch  comparison  in  the  areas  of  security,  functionality,  reli¬ 
ability,  cost,  flexibility  and  performance. 

Security 

Simply  stated,  the  goal  of  data  security  is  to  prevent  the  unau¬ 
thorized  or  unintended  disclosure,  modification  or  destruction  of 
information  and  to  prevent  denial  of  service.  This  goal  is  achieved 
by  implementing  countermeasures  to  a  set  of  perceived  security 
threats. 


To  achieve  multi-level  security,  cable  bus  and  message  switch 
security  measures  must  convincingly  counter  threats  previously  coun¬ 
tered  primarily  by  adninistrative  and  physical  means.  The  message 
switch  and  cable  bus  security  strengths  and  weaknesses  lie  in  their 
differing  abilities  to  inplement  the  additional  countermeasures 
inposed  by  this  considerably  more  demanding  environment. 

Present  day  command  center  security  measures  rely  largely  upon 
physical  and  adninistrative  steps  to  contain  command  center  com¬ 
ponents.  These  steps  include  clearing  all  personnel  to  a  system-high 
security  level  and  placing  components  within  a  limited  access  vault. 

The  message  switch  mainframe  or  the  cable  bus  backbone  and 
interface  units  are  components  that  would  be  installed  within  the 
vault.  The  vault  prevents  unauthorized  physical  access  thereby 
preventing  the  introduction  of  specialized  equipment  or  use  of  exist¬ 
ing  equipment  by  unauthorized  personnel. 

It  is  felt  that  sometime  in  mid-1982  or,  possibly  later,  a 
multi-level  secure  NFE  providing  access  to  the  AUTCDIN  II  network 
will  be  available.  The  NFE  and  AUTCDIN  II  multi-level  data  handling 
capabilities  will  necessitate  a  requirement  for  handling  single  level 
terminals  and  computers  which  are  not  necessarily  all  cleared  to  a 
system  high  security  level.  In  this  architecture,  ADP  measures  must 
be  implemented  in  both  the  cable  bus  and  message  switch  to  provide 
separation  of  sensitive  data  streams. 

Because  the  message  switch  terminates  all  terminal  and  computer 
communication  lines,  a  security  kernel  or  kernel-like  executive  is 
needed  to  mediate  invocations  of  the  different  communications  line 
software  modules.  To  insure  that  this  mediation  is  correct  and  fair, 
the  kernel  software  must  be  formally  verified.  The  executive  in  turn 
provides  support  for  other  software  modules  that  actually  inplement 
message  switcning  functions.  To  insure  that  multi-level  data  is  han¬ 
dled  correctly,  the  message  switch  specific  software  modules  must 
also  be  formally  verified. 

Separation  of  multi-level  data  streams  may  be  enforced  somewhat 
differently  in  the  cable  bus  architecture.  Since  each  interface  unit 
terminates  one  or  two  communication  lines,  each  unit  may  still  be 
operated  at  a  single  level.  This  means  that  only  address  detection 
and  security  level  checking  software  must  be  verified.  Address 
detection  software  monitors  messages  on  the  cable  bus  backbone  to 
determine  when  one  is  addressed  to  the  local  interface  unit.  The 
amount  of  interface  unit  software  to  be  verified  is  significantly 
less  than  that  required  in  the  message  switch.  While  each  interface 
unit  only  handles  messages  at  a  single  security  level,  the  cable 
backbone  transports  messages  of  varying  levels.  To  separate  data 
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streams  and  provide  protection  against  analysis  of  messages  and 
traffic  on  the  backbone,  data  encryption  may  be  used  to  encode  back¬ 
bone  message  header  and  data  information. 

When  mainframes  support  multi-level  data  streams,  cable  bus 
interface  units  may  at  any  one  time  have  messages  of  varying  security 
levels  within  them.  This  means  that  software  other  than  address 
detection  and  security  level  validation  modules  must  be  verified.  It 
is  believed  that  the  same  sofware  constructs  used  to  provide  verified 
separation  of  message  switch  data  streams  will  be  directly  applicable 
to  the  interface  unit. 

In  the  late  1980's  the  first  components  of  the  next  generation 
of  the  WWMCCS  Information  System  will  begin  to  appear  in  operational 
command  centers.  These  components  will  include  newer  WWMOCS  main¬ 
frames  as  well  as  teleconferencing  and  data  base  handling  mainframes. 

The  loading  induced  by  the  secure  handling  from  these  systems 
will  non-linearly  increase  the  complexity  of  the  message  switch, 
resulting  in  steadily  decreasing  performance  and  the  real  possibility 
of  overload  failure,  increased  difficulty  in  maintenance  of  the 
software  and  the  prospect  of  reverification  of  sizable  amounts  of 
software  with  the  addition  of  each  new  device. 

The  multi-level  secure  interface  unit,  on  the  other  hand,  will 
not  degrade  as  various  components  are  added  to  the  command  center. 
Each  additional  component  adds  an  interface  unit  to  provide  interface 
buffer  capacity  and  protocol  processing  cycles.  The  increased  load 
will  in  turn  increase  traffic  on  the  cable  bus  backbone.  However, 
the  application  of  backbone  technologies  such  as  fiber  optic  bundles 
which  support  gigabit  transfer  rates  should  reasonably  support  com¬ 
mand  center  backbone  requirements. 

It  is  believed  that  the  discussion  contained  in  the  body  of  this 
report  demonstrates  that  the  cable  bus  will  be  at  least  as  secure  as 
the  message  switch  architecture. 


The  message  switch  and  cable  bus  architectures  are  both  func¬ 
tionally  equivalent.  They  provide  terminal -to-computer  and 
computer-to-computer  communication  functions.  The  cable  bus,  how¬ 
ever,  has  an  inherent  broadcast  capability  since  all  interface  units 
see  each  message.  With  the  introduction  of  a  name  table  in  the  form 
of  an  associative  memory,  interface  units  can  be  logically  grouped 
together.  The  message  switch,  on  the  other  hand,  must  perform  all  of 
the  broadcast  functions  in  software  by  replicating  the  message  for 
each  communications  line  that  is  to  receive  it. 


Hie  MITRE  cable  bus  system  is  unique  among  cable  bus  systems  in 
that  it  uses  radio  frequency  modems  to  transport  digital  information. 
This  offers  the  capability  to  transmit  video  and  audio  signals  along 
with  the  digital  information  on  the  same  wire.  Finally,  this  radio 
frequency  transmission  technique  enables  the  creation  of  several  log¬ 
ically  distinct  network  systems  using  the  same  wire.  The  interface 
units  may  be  "tuned"  to  the  appropriate  digital  network.  In  the  com¬ 
mand  center  this  lends  itself  to  the  separation  of  communities  of 
interest  without  major  software  overhead. 


Since  system  reliability  cannot  be  directly  measured  without 
historical  records,  a  reliability  comparison  is  limited  to  a  discus¬ 
sion  of  architectural  weaknesses  which  would  make  the  message  switch 
or  cable  bus  inherently  more  or  less  reliable.  The  major  architec¬ 
tural  weakness  of  the  message  switch  is  clear.  A  failure  in  any  one 
of  the  message  switch  software  modules  or  a  failure  of  the  message 
switcn  hardware  halts  all  command  center  communications.  Protection 
against  these  failures  is  usually  implemented  in  the  form  of  redun¬ 
dant  systems.  This  is  expensive;  the  message  switch  and  its  inter¬ 
faces  with  other  components  must  be  replicated. 

The  cable  bus  architecture  distributes  its  processing  load  to 
each  interface  unit.  Each  interface  unit  is  a  passive  device  whose 
only  system  wide  failure  mode,  continuous  transmission,  can  be  pro¬ 
tected  against  by  a  simple,  inexpensive  watchdog  timer.  The  timer 
disables  the  interface  unit  if  it  has  been  continuously  transmitting 
for  an  extended  period.  The  cable  bus,  because  it  uses  a  single 
wire,  is  also  subject  to  overload.  Here,  redundancy  is  also  a  solu¬ 
tion.  However,  second  or  even  third  communication  backbones  are 
inexpensive. 

Finally,  the  physical  separation  of  interface  units  increases 
reliability.  A  failure  in  one  unit  will  not  damage  the  tables  or 
data  of  another  unit.  It  is  thus  concluded  that  the  cable  bus  has 
the  potential  for  significantly  more  reliable  operation  than  the  mes¬ 
sage  switch. 

Cost 

Costs  are  divided  into  fixed  initial  purchase  costs  and  recur¬ 
ring  maintenance  costs.  A  ten  year  life  cycle  is  psed  to  estimate 
recurring  expenses.  To  make  the  comparison  as  valid  as  possible, 
message  switch  costs  are  estimated  conservatively  low  and  cable  bus 
costs  are  estimated  conservatively  high. 


Fixed  message  switch  costs  are  estimated  for  terminal  interfac¬ 
ing  hardware,  computer  interfacing  hardware  and  minimal  hardware 
mainframe  support  for  these  interfaces  at  $51,554. 

The  recurring  cost  over  a  ten  year  life  cycle  is  $28,230.  Hie 
total  estimated  message  switch  cost  is  $79,784. 

Fixed  cable  bus  costs  are  estimated  for  the  cable  backbone  and 
for  interface  units  at  $45,700.  A  recurring  cost  of  $12,600  is 
estimated  for  each  cable  bus  systen.  Hie  total  estimated  cost  for 
each  cable  bus  system  is  $58,300. 

Given  that  WWMOCS  installs  these  systems  at  the  23  sites  where 
NFE  installations  are  planned,  the  comparative  costs  for  the  message 
switch  and  cable  bus  are: 


Message  Switch  ($79,784)  $1,835,032 

Cable  Bus  ($58,300)  $1,340,900 


The  cable  bus  is  approximately  27  per  cent  less  expensive  than  the 
message  switch. 

li/hen  reliability  issues  are  factored  into  the  cost  in  terms  of 
duplicating  message  switches  at  each  site  versus  duplicating  critical 
interface  units  and  cable  backbones,  the  savings  almost  double.  ' 


Message  Switch  ($159,568)  $3,670,064 

Cable  Bus  ($  78,200)  $1,798,600 


The  cable  bus  is  new  approximately  51  per  cent  less  expensive  than 
the  message  switch. 

Flexibility 


Hie  cable  bus  is  a  physically  modular  system.  Hiis  physical 
modularity  makes  the  cable  bus  amenable  to  growth  and  shrinkage  to 
meet  evolving  communication  requirements.  As  new  command  center 


devices  are  added  to  the  cable  bus,  interface  units  can  be 
correspondingly  added  to  provide  incremental  increases  in  buffering 
capacity  and  cpu  cycles.  Message  switch  incremental  increases  in 
buffering  capacity  and  cpu  cycles  tend  to  be  both  large  and  expen¬ 
sive. 

This  physical  modularity  also  has  the  advantage  that  new  device 
types  may  be  interfaced  to  the  cable  bus  without  affecting  the  opera¬ 
tion  of  existing  software  in  other  interface  units.  In  message 
switcn  architectures,  software  complexity  increases  non-linearly  with 
the  addition  of  each  new  device  type;  often  existing  software  and 
buffer  space  has  to  be  compressed  to  make  room  for  new  devices.  On 
the  other  hand,  interface  unit  software  can  be  tailored  to  special¬ 
ized  requirements  of  one  device  without  disturbing  software  for  other 
devices  of  the  same  class.  Therefore,  it  is  felt  that  the  cable  bus 
architecture  is  significantly  more  flexible  than  the  message  switch. 


Performance  comparisons  are  difficult  to  make  without  actual 
measurement  of  message  switch  and  cable  bus  systems.  As  a  basis  for 
making  performance  predictions,  measurements  of  the  NFE  and  MITRE 
cable  bus  are  used. 

NFE  measurements  are  obtained  from  measurements  of  an  early  ver¬ 
sion  of  the  NFE  called  the  Experimental  Network  Front  End  (ENFE) . 
Performance  measurements  of  a  newer  NFE  called  the  Interim  Network 
Front  End  (INFE)  are  not  yet  available.  Both  NFEs  are  supported  by  a 
general  purpose  operating  system,  UNIX.  The  general  purpose  nature 
of  UNIX  severely  limits  throughput.  A  new  operating  system  now. under 
construction  may  increase  NFE  performance  by  as  much  as  a  factor  of 
three  to  five. 

Cable  bus  measurements  were  obtained  by  direct  measurement  of  a 
cable  bus  test  bed  installed  as  a  part  of  this  program.  Throughput 
and  bandwidth  measurements  were  made  of  the  basic  cable  bus  interface 
units  and  of  the  cable  bus  Transmission  Control  Protocol  (TCP)  imple¬ 
mentations.  The  TCP  implements  command  center  virtual  circuit  and 
datagram  functions.  Modifications  were  made  to  the  cable  bus  proto¬ 
cols  to  eliminate  duplicate  functions  and  decrease  overhead.  These 
modifications  and  the  experimental  results  that  provide  the  impetus 
for  them  are  documented  in  the  report. 

The  ENFE  was  measured  as  having  an  average  maximum  bandwidth  of 
33. 5K  bits  per  second  (bps) .  Cable  bus  throughput  was  measured  at 
the  virtual  circuit  level  at  28. 9K  bps.  The  slowness  of  the  cable 
bus  can  be  attributed  to  its  outdated  microprocessor-base  and  unso¬ 
phisticated  (byte-at-a-time)  test  bed  hardware  interfaces. 
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If  the  new  NFE  operating  system  performs  as  expected,  a  three  to 
five  fold  increase  in  performance  may  be  forthcoming.  Thus  NFE  per¬ 
formance  estimates  of  100. 5K  bps  to  167. 5K  bps  might  be  expected. 
During  FY  80  a  new  16-bit  microprocessor  interface  unit  will  be 
tested.  It  is  expected  that  this  system  will  also  perform  from  five 
to  ten  times  faster  than  present  test  bed  interface  units.  Thus 
cable  bus  performance  estimates  of  144. 5K  bps  to  289K  bps  might  be 
expected. 

Effective  cable  bus  and  message  switch  performance  is  determined 
largely  by  buffering  capacity  and  the  arrival  rate  of  "to-be- 
transmitted"  messages.  The  number  of  "to-be-transmitted"  messages  is 
dependent  upon  the  number  of  processor  cycles  available  to  set  up 
message  transmission.  Since  the  message  switch  architecture  uses  a 
single  cpu,  the  number  of  available  message-set  up  processor  cycles 
is  limited  by  the  single  cpu  speed.  The  buffering  capacity  is  lim¬ 
ited  by  the  capacity  of  the  message  switch  main  memory.  The  cable 
bus,  on  the  other  hand,  uses  a  cpu  for  each  interface  unit.  Thus, 
cable  bus  cpu  cycles  and  buffering  capacity  are  determined  by  the 
aggregate  number  of  interface  units  effectively  handled  by  the  cable 
backbone. 

For  performance  comparison  purposes,  it  is  assumed  that  the 
cable  bus  can  effectively  handle  four  interface  units  (a  larger 
number  is  somewhat  more  realistic) .  If  as  estimated  each  interface 
unit  is  abj.e  to  operate  at  five  to  ten  times  its  present  rate,  from 
144. 5K  bps  to  289K  bps,  the  aggregate  cable  bus  performance  of  four 
interface  units  will  be  somewhere  between  578K  bps  and  1156K  bps. 
Based  on  these  ranges,  the  cable  bus  may  be  significantly  faster  than 
the  message  switch  in  the  near  term. 

Conclusion 

Due  to  the  early  stages  of  development  of  both  the  cable  bus  and 
the  message  switcn,  conclusive  opinions  as  to  their  applicability  to 
the  command  center  are  necessarily  analytic  and  not  empirical.  How¬ 
ever,  based  on  the  foregoing  comparison  it  appears  that  the  cable  bus 
will  be  as  secure  as  the  message  switch,  from  20  per  cent  to  50  per 
cent  less  expensive,  significantly  more  reliable  and  have  better 
overall  performance  with  a  flexibility  for  incremental  growth  sur¬ 
passing  the  message  switch  architecture.  FY  80  development  and  test¬ 
ing  should  enable  less  subjective  comparisons.  FY  80  work  will  con¬ 
tinue  cable  bus  protocol  development,  a  cable  bus  virtual  terminal 
protocol  with  graphics  capabilities  will  be  investigated  and  a  cable 
bus  system  will  be  installed  at  DCA  Reston  in  order  to  begin  evaluat¬ 
ing  the  system  in  a  command  center  setting.  In  a  related  MITRE 
internal  research  and  development  effort,  a  new,  faster  interface 
unit  will  be  developed  and  tested. 
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1.0  INTRCDUCTION 


This  report  documents  the  FY  79  activities  of  a  MITRE  Mission 
Oriented  Investigation  and  Experimentation  (MOIE)  program  initiated 
in  April  1978  and  sponsored  by  the  Defense  Communications  Agency 
(DCA) .  The  purpose  of  MOIE  programs  is  to  develop  MITRE  expertise 
and  to  investigate  new  technologies  of  potential  interest  to  the 
sponsor . 

1.1  Background 

The  World  Wide  Military  Command  and  Control  Systems  (WWMCCS) 
Command  Centers  are  interconnected  via  an  ARPANET-like  long-haul  net¬ 
work.  In  the  near  future,  these  command  centers  will  be  connected  to 
the  AUTODIN  II  long-haul  network.  A  Network  Front  End  (NFE)  minicom¬ 
puter  will  be  used  to  interface  command  center  mainframes  and  termi¬ 
nals  to  AUTODIN  II.  An  expanded  NFE  could  conceivably  serve  as  a 
centralized  local  network  message  switch  to  interconnect  additional 
computers,  terminals  and  other  components  of  a  WWMCCS  Command  Center. 

This  program  is  investigating  the  applicability  of  a  distributed 
cable  bus  local  area  network  to  interconnect  command  center  com¬ 
ponents  to  each  other  and  to  offload  NFE  terminal  handling  functions. 
To  measure  cable  bus  applicability  to  the  command  center,  the  FY79 
program  focused  on  a  comparison  of  cable  bus  and  NFE-based  message 
switch  interconnection  architectures  in  terms  of  security,  func¬ 
tionality,  reliability,  flexibility,  cost  and  performance. 

1.2  Report  Organization 

This  report  is  divided  into  eight  sections.  Section  2  outlines 
the  WWMCCS  command  center,  its  purpose  and  components,  and  defines 
future  WWMCCS  command  center  communication  requirements.  Section  3 
describes  the  components  of  local  area  networks  and  distinguishes 
between  centralized  and  distributed  architectures.  Specfic  instances 
of  these  architectures,  viz.,  the  message  switch  and  the  cable  bus. 
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are  described.  Section  4,  Analysis  Activity  compares  the  two  archi¬ 
tectures  in  terms  of  security,  functionality,  reliability,  cost  and 
flexibility.  Section  5,  Development  Activity,  reports  on  the  estab¬ 
lishment  of  a  cable  bus  test  bed  set  up  to  provide  an  initial  start¬ 
ing  point  for  the  experimental  activity.  Section  6,  Experimental 
Activity,  contains  a  comparison  of  the  performance  of  a  postulated 
WWMCCS  message  switch  and  the  cable  bus  test  bed.  Section  7 
describes  a  protocol  architecture  that  evolved  during  the  year  to 
support  command  center  requirements.  Section  8  contains  a  synopsis 
and  indicates  the  areas  of  future  emphasis. 


2.0  THE  WNMCCS  COMMAND  CENTER 


This  section  contains  a  brief  outline  of  the  WWMCCS  command 
center  and  its  present  and  projected  communication  requirements. 


2.1  The  Conmand  Center  Environment 

The  World  Wide  Military  Command  and  Control  System  (WW1CCS)  is 
responsible  for  the  coordination  of  all  U.S.  military  activities. 
World  events  are  monitored  toy  interconnected  warning  systems  and 
electronic  information  management  tools  concentrated  in  geographi¬ 
cally  distinct  military  command  centers.  The  management  tools 
employed  might  include  devices  for  receiving  information  (such  as 
sensors  or  telemetry  equipment) ,  large  data  base  machines  for  infor¬ 
mation  retrieval,  devices  for  processing  or  updating  the  data  col¬ 
lected  and  computer  controlled  display  devices.  The  output  from 
these  management  tools  facilitates  high-level  decision  actions  and/or 
tactical  control  for  military  activities. 

Thus,  a  smoothly  functioning,  well-designed  command,  control  and 
communications  system  enables  the  speed,  processing  power  and 
retention/retrieval  capabilities  of  the  computer  to  be  successfully 
combined  with  human  intuition.  The  following  scenario,  depicted 
graphically  in  Figure  1,  is  an  example  of  the  desired  integration: 

Geographically  separated  computers  and  sensors  transmit 
information  over  communication  channels.  Received  data  is 
displayed  as  a  diagram  or  sketch  on  a  CRT.  A  specialist 
manipulates  the  display  under  computer  control.  The  display 
is  modified  with  data  base  information  resulting  in  a  visual 
chart  with  a  color-coded  decision  variable.  The  enhanced 
chart  is  then  transmitted  to  a  command  center  for  viewing  on 
wall-sized  screens  by  groups  of  senior  decision  makers. 
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of  messages  with  varying  levels  of  security.  These  devices  provide 
service  for  voice,  typed  text,  digital  facsimile,  closed-circuit 
T.V. ,  commercial  T.V. ,  commercial  radio  and  a  variety  of  recording 
facilities. 

The  command  center  computer  facility  now  houses  Honeywell  6000 
mainframe  computers  and  a  variety  of  terminal  devices  including 
Visual  Information  Processors  (VIPs) ,  IBM  2741s,  Tektronix  4014 
grapnics  terminals,  Tektronix  4632s,  remote  line  printers  (RLP  300s) 
ana  IBM  2250s  with  light  pens.  A  detailed  discussion  of  command 
center  components  is  contained  in  Acker  fit _ al . ^ 

In  addition  to  present  day  Wl'JMCCS  Honeywell  6000  series  comput¬ 
ers,  individual  command  centers  of  the  1980's  are  likely  to  include 
the  next  generation  MJMCCS  Information  System  mainframe,  Network 
Front  Olds  to  offload  networking  software,  the  next  generation  VJWMCCS 
terminals,  such  as  the  Tektronix  Colorgraphics  4027,  plasma  panel 
terminals,  intelligent  terminals,  teleconferencing  machines,  data 
base  machines,  an  automated  text  and  message  handling  system  (includ¬ 
ing  a  document  preparation  capability  via  a  text  editor  and  for¬ 
matter),  hard-copy  graphics  capabilities,  an  electronic  mail  capabil¬ 
ity  for  voice,  typed  text,  digital  facsimile  and,  possibly,  an  intel¬ 
ligence  system. 

This  expanded  configuration  enables  the  integration  of  all  the 
monitoring,  analysis  and  communications  activities  throughout  the 
command  center.  A  local  area  network  is  the  ideal  vehicle  for  this 
needed  integration. 

2.3  Command  Center  Local  Network  Models 

TVo  models  of  local  area  networks  receive  primary  attention  in 
this  report,  the  message  switch  model  and  the  cable  bus  model. 

Figure  2  depicts  the  message  switch  architecture.  The  message 
switcn  is  characterized  by  a  medium  scale  mini-computer  terminating 
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communications  lines  from  command  center  components.  Software  within 
the  message  switch  provides  virtual  interconnection  of  the  communica¬ 
tion  lines. 

In  the  WWMCCS  environment,  the  message  switch  must  provide 
interconnection  of  the  present  day  WWMCCS  Honeywell  6000  series 
(H6000)  mainframe  computers  and  a  variety  of  terminals.  In  the 
future  these  requirements  will  be  expanded,  as  discussed  above,  to 
include  interconnection  of  the  next  generation  WWMCCS  Information 
System  (WIS) ,  a  Network  Front  End  (NFE)  which  interfaces  the  command 
center  to  a  long-haul  packet-switched  network,  a  teleconferencing 
facility,  a  data  base  machine,  an  automated  text  message  handling 
facility,  possibly  an  intelligence  mainframe  and  new  intelligent  ter¬ 
minals  with  graphics  capabilities. 

Figure  3  depicts  the  cable  bus  architecture.  The  cable  bus  is 
characterized  by  a  single  wire  communications  medium  interconnecting 
microprocessor-based  interface  units.  Each  command  center  communica¬ 
tion  line  is  terminated  by  an  interface  unit.  Software  in  the  inter¬ 
face  units  provide  virtual  interconnection  of  the  communication 
lines. 

Although  the  two  models  must  address  the  same  problems  to'  pro¬ 
vide  the  required  integration  among  the  command  center  components, 
the  solutions  are  often  strikingly  different.  It  is  the  comparison 
of  these  models  in  the  command  center  environment  which  is  the  focus 
of  much  of  this  report. 


A  local  area  network  consists  of  a  set  of  communication  lines  to 
carry  data  and  a  set  of  protocols  to  manage  the  data  flow.  A  proto¬ 
col  is  a  set  of  mutually  agreed  upon  conventions  which  enables  the 
orderly  exchange  of  information  between  two  functionally  related  ele¬ 
ments.  Whenever  there  is  communication  between  functionally  dissimi¬ 
lar  entities,  an  interface  must  be  defined.  The  communications 


network  protocols  and  interfaces  delineate  the  capabilities  of  the 
network.  Based  on  the  command  center  components  described  above,  the 
capabilities  which  must  be  supported  by  a  military  command  center 
network  are  as  follows: 

•  interconnection  between  hundreds  of  terminals  of  various 
types  and  tens  of  computers  ranging  from  microcomputers  to 
large  systems  scattered  through  out  a  command  center 

•  local  terminal  to  host  communications  at  up  to  19. 2K  bps  and 
terminal  virtualization  by  mapping  characteristics  for  vari¬ 
ous  terminals  and  computers  into  a  standard  representation 

•  interfacing  of  terminals  to  the  network  inexpensively,  i.e., 
not  more  than  several  hundred  dollars  per  terminal 

•  local  computer-to-computer  communication  with  data  rates  of 
millions  of  bits  per  second 

•  interfacing  of  computers  via  high  speed  multiplexed  inter¬ 
faces  capable  of  supporting  many  virtual  connections 

•  offloading  network  specific  interface  software  from  mainframe 
computers  by  implementing  such  interface  protocols  as  X.25 
and  HFP  (Host-to-Frontend  Protocol)  in  the  network 

•  load  leveling  and  other  resource  sharing  concepts  to  enable 
efficient  utilization  of  resources  and  to  minimize  delay  dur¬ 
ing  day-to-day  and  crisis  operations 

•  accessing  of  remote  resources  via  gateways  to  other  networks 

Additionally  the  network  should  support  the  following  applica¬ 
tions: 

•  exchange  of  critical  messages  (voice,  typed  text,  facsimile) 
with  multi-precedence  levels 

•  preparation  and  transmission  of  documents  (with  graphics  and 
text)  of  print  quality 

•  access  of  remote  data  bases 

•  execution  of  standard  command  center  application  programs 
whose  "location"  (host/net)  is  not  known  and  access  of  data 
bases  whose  physical  location  is  not  known 
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Of  utmost  importance  is  the  requirement  for: 

•  the  capability  to  exchange  intelligence  and  other  sensitive 
information  among  qualified  parties  without  fear  of  its 
accidental  or  intentional  compromise,  modification  or  des¬ 
truction 


2.4.1  The  Protocol  Requirements 

The  ability  of  the  command  center  network  to  support  the 
requirements  delineated  above  is  very  much  a  function  of  local  area 
network  protocol  architecture  and  its  implementation .  In  order  to 
enable  remote  devices,  processes  or  users  to  exchange  information, 
certain  standard  protocol  mechanisms  must  exist.  A  hierarchical  mul¬ 
tilayered  protocol  structure  separates  required  communication  func¬ 
tions.  In  general,  each  level  in  the  hierarchy  is  responsible  only 
for  the  management  of  a  particular  class  of  resource  (such  as  channel 
capacity,  processors  or  address  space) .  This  separation  results  in 
both  simplicity  and  flexibility.  The  replacement  of  any  protocol 
layer  should  be  transparent  to  the  surrounding  layers  if  the  inter¬ 
faces  to  the  adjacent  layers  are  preserved. 

Certain  protocol  mechanisms  are  essential  if  the  multiplicity  of 
disparate  computing  elements  in  the  command  center  model  are  to  be 
joined  into  a  unified  whole.  File  access  mechanisms  are  necessary  to 
enable  data  base  accesses  between  computers  within  a  command  center 
and  globally  between  centers.  Virtual  terminal  and  graphics  proto¬ 
cols  are  necessary  to  support  the  many  terminals  within  command 
centers  by  mapping  terminal  characteristics  into  standard  virtual 
terminal  representations.  Virtual  circuits  are  necessary  for 
extended  interactions  requiring  the  exchange  of  reliable  data 
streams.  Datagrams  are  useful  for  one-way  and  isolated  exchanges. 

Virtual  circuits  and  datagrams  require  the  support  of  additional 
basic  protocol  mechanisms.  These  mechanisms  are:  addressing  (using 
a  hierarchical  address  space  to  enable  both  intranetwork  and  inter¬ 
network  addressing),  congestion  and  flow  control,  reliability  and 


out-of-band  signaling  (to  enable  urgent  information  to  be  desig¬ 
nated).  Taken  together,  all  of  these  basic  protocol  mechanisms  must 
be  flexible  and  robust  enough  to  support  communications  over  diverse 
transmission  media  with  characteristics  that  vary  in  bandwidth, 
delay,  error  rates  and  broadcast  capability. 

At  the  very  lowest  levels  of  the  architecture  are  the  network 
specific  mechanisms  used  for  the  access  and  control  of  the  particular 
transmission  medium.  This  architecture  is  shown  in  Figure  4. 

2.4.2  The  Interface  Requirements 

In  addition  to  basic  transport  facilities,  the  network  should 
offer  a  variety  of  standard  hardware  and  software  interfaces  so  that 
a  wide  spectrum  of  devices  can  be  attached  with  relative  ease. 

2. 4. 2.1  Hardware.  The  network  should  offer  standard  electrical 
serial  interfaces  for  terminals  such  as  RS-232C  and,  perhaps  later, 
RS-422/3 .  Both  synchronous  and  asynchronous  serial  interfaces  should 
be  supported.  A  parallel  interface  must  be  provided  to  enable  high¬ 
speed  direct  memory  access  (DMA)  transfers  from  computer  devices  to 
and  from  the  network. 

2. 4. 2. 2  Software.  The  network  should  support  data  link  control 
interface  protocols  to  provide  error  checking  and  failure  control  of 
transmitted  data.  An  international  standard  which  does  this  at  the 
bit  level  is  HDLC  (high-level  data  link  control);  an  IBM  standard 
performing  the  same  functions  at  the  byte  level  is  BSC  (binary  syn¬ 
chronous  data  link  control) .  Classically,  these  have  been  imple¬ 
mented  in  software.  Recently,  Western  Digital  has  announced  an  HDLC 
integrated  circuit  chip. 

If  a  mainframe  has  the  capabilities  to  support  virtual  circuit 
software,  that  software  should  be  implemented  in  the  mainframe.  How¬ 
ever,  for  any  one  of  a  number  of  reasons,  the  mainframe  may  not  be 
able  to  cleanly  support  a  virtual  circuit  inplementation.  For  these 
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FIGURE  4 

COMMAND  CENTER  PROTOCOL  LAYERING 
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cases,  the  local  area  network  should  provide  the  capability  to 

offload  the  mainframe  virtual  circuit  software.  To  do  this,  an 

interface  protocol  is  required  which  allows  the  mainframe  to  direct 

the  activities  of  the  local  interface  unit.  A  prime  candidate  for 

(2) 

this  interface  protocol  is  the  Host-to-Frontend  Protocol  (HFP) ' 
currently  used  between  the  NFE  and  the  H6000  host.  Another  possibil¬ 
ity  is  to  use  the  CCITT  X.25  interface  protocol.  Implementation  of 
an  interface  protocol  in  the  local  network  would  enable  the  network 
specific  protocols  to  be  offloaded  from  the  host  computers.  Ideally, 
this  offloading  provides  a  siirplified  and  easily  implemented  network 
interface.  The  resultant  network  interface  unit  would  then  be  capa¬ 
ble  of  being  directed  by  devices  and  processes  with  diverse  require¬ 
ments. 

2.4.3  Security  Requirements 

The  design  of  a  command  center  communications  system  must 
respond  to  all  recognizable  threats  to  data  security.  It  is  reason¬ 
able  to  assume  that  appropriate  physical  and  procedural  security 
measures  are  followed  in  and  around  the  command  center  so  that  cer¬ 
tain  kinds  of  threats  lie  outside  the  scope  of  this  design.  The  pos¬ 
sible  threats  generated  by  cleared  and  uncleared  personnel . which 
could  lead  to  exposure,  modification  or  destruction  of  information  or 
to  denial  of  service  must  be  catalogued  and  appropriate  countermeas¬ 
ures  employed.  Threats  arising  from  accidental  causes  or  from  system 
component  failures  must  also  be  considered.  The  goal,  of  the  design 
is  an  efficient  communications  network  which  can  simultaneously  serve 
users  of  sensitive  information  at  all  security  levels  without  the 
possibility  of  information  compromise. 


3.0  LOCAL  AREA  NETWORKS 


A  local  area  network  is  a  high  speed  communications  network 
interconnecting  a  set  of  computing  elements  over  an  area  potentially 
spanning  several  kilometers.  The  success  of  a  network  is  determined 
by  how  well  these  computing  elements  are  able  to  exchange  information 
(messages)  with  one  another.  A  network's  ability  to  transmit  and 
receive  messages  with  speed  and  reliablity  is  determined,  to  an 
extent,  by  the  degree  of  independence  of  its  elements.  The  degree  of 
independence  is  a  function  of  the  kind  of  control  that  a  network  node 
applies  to  each  message  as  it  traverses  from  source  to  destination. 

Different  local  area  network  control  architectures  are  named  by 
their  interconnection  topologies:  star,  ring  and  bus.  The  star-type 
architectures  fall  into  a  group  of  networks  which  provide  centralized 
control  of  message  traffic.  Bus  and  ring  networks  generally  render 
decentralized  control  of  message  traffic,  thereby  providing  nodal 
independence.  Centralized  control  increases  the  complexity  of  the 
resultant  network,  while  decreasing  the  reliability.  A  message 
switch  based  on  the  WWMCCS  Network  Front  End  (NFE)  is  an  example  of  a 
star  configuration,  and  the  MITRE  cable  bus  is  an  example  of  a  dis¬ 
tributed  architecture.  To  provide  background  for  a  comparative 
analysis,  the  distinguishing  characteristics  of  a  star  architecture 
like  the  NFE,  a  bus  architecture  like  the  MITRE  cable  bus  and,  for 
completeness,  thf  ring  architecture  are  discussed. 

3.1  Central  Control  -  Stars  and  Modified  Stars 

Centralized  topologies  evolved  out  of  the  economics  of  producing 
computers  in  the  mid-1960's.  To  be  cost  effective,  large  computers 
were  built  and  maintained  centrally.  Centrally  controlled  architec¬ 
tures  are  typified  by  complex  primary  nodes  and  relatively  simple 
secondary  nodes.  The  secondary  nodes  implement  only  very  basic  com¬ 
munications  functions.  Primary  nodes  support  the  remaining 
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functions;  routing,  flow  control,  reliability,  protocol  translation 
and,  sometimes,  security. 


The  star  network,  shown  in  Figure  5a,  is  represented  by  a  single 
primary  node  and  terminal  nodes.  The  primary  node  supports  message 
routing  and  character  set  translation.  The  terminal  nodes  rely  com¬ 
pletely  on  the  primary  node  for  all  communications  functions.  This 
simple  architecture  is  commonly  used  by  time  sharing  systems  in  which 
messages  flow  between  a  number  of  terminal  terminals  and  a  primary 
central  processor.  The  advantage  of  this  architecture  is  that  termi¬ 
nal  nodes  are  inexpensive  to  construct. 

When  computer  mainframes  with  terminal  node  communication  capa¬ 
bilities  are  added  to  the  star  network  architecture,  a  modified  star 
architecture,  shown  in  Figure  5b,  results.  Since  failure  by  one  com¬ 
puter  node  should  not  affect  the  operation  of  the  primary  node  or 
other  secondary  nodes,  communications  are  implemented  with  elements 
of  defensiveness  not  found  in  simple  star  architectures.  Since  the 
mainframe  nodes  may  be  different,  elements  of  generality  are 
increased  in  the  primary  node  implementation.  Taken  together,  these 
elements  support  a  mutually  suspicious  environment  which  is  signifi¬ 
cantly  more  complex  than  the  simple  star  architecture  described 
above. 

The  clear  drawback  to  the  topologies  shown  in  Figure  5  is  relia¬ 
bility.  If  the  primary  node  fails,  network  communications  are 
halted.  The  primary  node  must  operate  correctly  in  the  face  of 
simultaneous  high  spoed  communications  with  computer  secondary  nodes 
and,  in  addition,  have  the  capacity  for  generalized  protocol  transla¬ 
tions,  virtualization  and  dynamic  routing  functions. 

3.2  Decentralized  Control  -  Rings  and  Cable  Buses 

Initially,  the  centralized  topologies  were  implemented  with  com¬ 
paratively  large  mainframes.  As  technology  advanced,  some  of  the 
communications  functions  were  offloaded  to  large  mini-computers  to 


relieve  the  mainframe  of  communi cations  overhead.  Decreasing 
hardware  costs  are  making  it  feasible  to  distribute  primary  node 
capabilities  to  each  secondary  node.  The  cable  bus  and  ring  archi¬ 
tectures  are  examples  of  this  evolutionary  step. 

Ring  and  cable  bus  architectures,  shown  in  Figure  6,  are  charac¬ 
terized  by  a  high  bandwidth  single-wire  communications  medium  inter¬ 
connecting  intelligent  interface  units.  The  interface  units  have  two 
major  functions:  they  manage  message  communications  over  the  medium, 
and  they  interface  user  devices  (computers,  terminals  and  other  peri¬ 
pheral  devices)  to  the  communications  medium.  The  cable  bus  and  ring 
bus  architectures  are  an  intermediate  hybrid  of  the  computer  peri¬ 
pheral  bus  and  the  centrally  connected  network.  The  speeds  attain¬ 
able  through  these  architectures  are  tantamount  to  those  of  a  peri¬ 
pheral  bus  but,  at  the  same  time,  in  interconnecting  standalone  com¬ 
puter  devices  both  the  ring  and  cable  bus  must  take  on  aspects  of 
defensiveness  and  generality  common  to  centrally  connected  networks . 
To  some  extent,  the  homogeneity  of  the  interface  units  sinplifies 
intra-interface  unit  protocols  by  allowing  assumptions  to  be  made 
about  interface  unit  processor  speed,  word  size,  buffering  capacity 
and  timeout  values  which  are  untenable  in  the  fully  connected 
environment.  These  architectures  eliminate  the  singular  dependence 
on  a  central  node  by  distributing  message  control  to  each  network 
node  without  compromising  the  sinplicity  of  the  nodes.  This  is  made 
possible  by  several  architectural  factors: 

•  The  homogeneity  of  the  cable  and  ring  relaxes  the  degree  of 
mutual  suspicion;  each  of  the  nodes  are  running  a  copy  of  the 
same  software. 

•  No  routing  is  required;  each  node  sees  all  messages  and  cap¬ 
tures  those  messages  whose  destination  address  matches  its 
own. 

•  Each  node  provides  its  own  translation  from  device  specific 
protocols  to  generalized  virtual  protocols.  Since  the  trans¬ 
lation  is  "closer"  to  the  device,  the  degree  of  generality 
found  in  centralized  translations  can  be  reduced.  The  node's 


recognition  of  a  specific  terminal  type  or  of  a  computer's 
word  size  is  an  immediate  example  of  this  relaxation. 


The  character  of  these  architectures  is  affected  by  interface 
unit  algorithms  used  to  access  the  transmission  medium.  Various 
algorithms  exist  to  establish  temporary  communications  medium  owner¬ 
ship  by  one  interface  unit  in  the  face  of  a  set  of  interface  units 
which  simultaneously  wish  to  transmit  a  message.  If  these  algorithms 
are  centrally  controlled,  decentralized  architectures  will  take  on 
many  of  the  deficiencies  of  centralized  architectures.  The  distinc¬ 
tion  between  the  ring  and  cable  bus  architectures  is  found  in  these 
algorithms. 

Ring  architectures  have  employed  a  number  of  different  algo¬ 
rithms  for  this  purpose.  These  algorithms  are  described  in  Liu.^ 
The  major  disadvantage  of  ring  architectures  from  a  command  center 
point  of  view  is  that  each  of  the  algorithms  requires  an  interface 
unit  to  become  an  active  element  in  the  network.  Each  interface  unit 
must  pass  on  a  "time-to-transmit"  token,  or  "take-a-message-offM  the 
network,  or  be  in  timed  synchrony  with  other  units  to  store  data  in 
"slots".  If  an  interface  fails  while  it  is  in  this  active  mode, 
manual  or  semi-automatic  recovery  measures  are  required. 

The  cable  bus  architecture  does  not  have  this  problem.  Various 
cable  bus  architectures  are  described  in  Trooper. ^  Cable  bus  inter¬ 
face  units  implement  a  contention  algorithm  to  establish  medium  own¬ 
ership.  There  are  a  variety  of  contention  algorithms.  The  most  suc¬ 
cessful  ones  check  to  see  if  the  medium  is  in  use  before  transmitting 
a  message.  This  lessens  the  probability  of  one  interface  unit  damag¬ 
ing  the  transmission  of  another  unit.  Due  to  signal  propagation 
delay,  there  is  a  small  time  lag  between  the  moment  of  transmission 
by  one  unit  and  the  moment  that  another  interface  unit  is  able  to 
detect  a  busy  medium.  Simultaneous  transmissions  during  this  time 
interval  cause  collisions.  Thus  the  effectiveness  of  these 
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contention  algorithms  is  determined  by  interface  unit  adeptness  at 
detecting  collisions. 

Recent  advances  in  contention  algorithm  technology  have  produced 
theoretical  communication  medium  bandwidth  utilization  of  85  to  95 
per  cent.^  These  advances  and  the  decreasing  cost  of  interface  unit 
hardware  are  the  major  reasons  for  recent  interest  in  the  future  of 
cable  bus  systems. 

3.3  Centralized  and  Decentralized  Inolementations 

The  message  switching  functions  of  the  Network  Front  End  exem¬ 
plifies  a  centralized  architecture  and  the  MITRE  cable  bus  exempli¬ 
fies  a  decentralized  architecture.  These  systems  are  used  for  quan¬ 
titative  comparisons  in  this  report. 

3.3.1  Network  Fr.ont.iftd 

The  Network  Front  End  (NFE)  uses  a  PDP-11/70  minicomputer  to 
support  message  switching  software.  The  system  was  developed  for  DCA 
to  interface  command  center  Honeywell  computers  and  terminals  to 
packet  switched  networks.  Originally,  the  NFE  was  interfaced  to  the 
ARPA  network.  It  will  soon  be  interfaced  to  the  forthcoming  ADTCDIN 
II  network.  The  message  switching  software  is  programmed  in  a  high 
level  language  called  'C'.  Both  the  message  switching  software  and 
the  C  language  are  supported  by  UNIX,  a  general  purpose  operating 
system  developed  by  Bell  Laboratories. 

The  PDP-11/70  has  512K  bytes  of  RAM,  a  disk,  a  synchronous  ter¬ 
minal  multiplexor  interface,  an  asynchronous  terminal  multiplexor 
interface,  as  well  as  high-speed  direct  memory  access  interfaces  to 
the  packet  switched  network  and  the  Honeywell  computer. 

The  message  switching  software  implements  the  Host-to-Frontend 
Protocol  (HFP)  to  interface  with  the  Honeywell  computers.  It  also 
implements  packet  switch  network  specific  software  to  interface  to 
the  ARPA  and  AUTCDIN  II  networks.  The  HFP  software  is  composed  of 
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several  layers.  One  of  the  layers  is  reponsible  for  management  of 
virtual  channels  between  a  Honeywell  computer  and  a  front  end.  The 
other  layers  interface  commands  and  data  from  Honeywell-based  pro¬ 
grams  to  the  packet  network  specific  software. 

The  NFE  is  still  in  an  experimental  form.  Extensive  measure¬ 
ments  of  the  NFE  in  this  form  have  been  taken. ^  These  measurements 
are  used  as  a  basis  for  comparison  with  the  MITRE  cable  bus. 

3.3.2  MITRE  Cable  Bus 

The  MITRE  cable  bus  is  based  on  a  system  which  was  developed  at 
MITRE  Bedford.  It  is  currently  in  operation  there  and  at  a  number  of 
government  sites.  Details  of  the  system  can  be  found  in  Hopkins, ^ 
Malis^  and  Hopkins  _ §i.  ^ 

The  system  uses  standard  Community  Antenna  Television  (CATV) 
coaxial  cable  components  and  microprocessor  based  interface  units  to 
interface  subscriber  computers  and  terminals.  The  cable  bus  consists 
of  two  parallel  coaxial  cables,  one  inbound  and  the  other  outbound, 
which  ate  connected  at  the  headend  as  shown  in  Figure  7.  This  archi¬ 
tecture  takes  advantage  of  well-developed  unidirectional  CATV  com¬ 
ponents.  The  CATV  components  include  coaxial  cable,  wideband  linear 
amplifiers  to  boost  the  signal  where  needed,  splitters  to  divide  the 
cable  into  a  branched  structure  which  easily  conforms  to  building 
topology,  and  taps  to  provide  access  to  the  cable. 

The  interface  units  are  designed  to  transmit  on  the  inbound 
cable  and  receive  on  the  outbound  cable.  The  interface  units  contain 
Radio  Frequency  (RF)  modems  and  microprocessor  systems. 

The  Radio  Frequency  modems  modulate  a  carrier  signal  to  transmit 
the  digital  information.  A  data  rate  of  307. 2K  bps  is  used  on  the 
cable  which  occupies  about  1  MHz  of  bandwidth  around  the  24  MHz  fre¬ 
quency.  The  remaining  bandwidth  can  be  used  to  carry  other  digital 
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Interface  Unit 


Tap/Spl itter 


FIGURE  7 
MITRE  CABLE  BUS 


channels,  video  in  the  form  of  closed  circuit  and  off  the  air  TV  and 
audio. 

The  interface  unit  microprocessor  system  uses  about  20  MSI  and 
LSI  integrated  circuits.  The  integrated  circuits  include  a  MOS  6502 
Microprocessor,  2K  bytes  of  programmable  read  only  memory  (PRCM) , 
2K  bytes  of  random  access  memory  (RAM) ,  a  clock,  and  interface  cir¬ 
cuits  to  the  modems  and  user  devices. 
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4.0  ANALYSIS  ACTIVITY 

Hie  analysis  activities  discussed  in  the  following  sections  com¬ 
pare  the  capabilities  of  the  cable  bus  and  the  message  switch  archi¬ 
tectures  to  meet  five  command  center  requirements: 

•  Security 

•  Functionality 

•  Reliability 

•  Cost 

•  Flexibility 

Versions  of  the  NFE  and  cable  bus  which  support  all  perceived 
WWMCCS  command  center  requirements  do  not  exist  at  present.  There¬ 
fore,  NFE  and  cable  bus  comparisons  are  necessarily  analytic  and  not 
empirical  in  nature.  This  is  particularly  true  in  the  Security, 
Reliability,  and  Cost  analysis  sections  where  experience  with  opera¬ 
tional  prototypes  is  required  to  make  definitive  statements. 

4.1  Security 

Simply  stated,  the  goal  of  data  security  is  to  prevent  the  unau¬ 
thorized  or  unintended  disclosure,  modification  or  destruction  of 
information  and  to  prevent  denial  of  service.  This  goal  is  achieved 
by  implementing  countermeasures  to  a  set  of  perceived  security 
threats. 

The  analysis  approach  has  been  to  look  at  the  evolving  WWMCCS 
security  environment  in  the  context  of  comparative  message  switch  and 
cable  bus  security  measures.  The  WWMCCS  command  center  security  pol¬ 
icies  may  evolve  from  a  single-level,  system-high  security  policy  to 
a  multi-level  security  policy  in  the  mid-to-late  1980's. 

To  achieve  multi-level  security,  cable  bus  and  message  switch 
security  measures  must  convincingly  counter  threats  previously  coun¬ 
tered  primarily  by  administrative  and  physical  means.  The  message 
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switch  and  cable  bus  security  strengths  and  weaknesses  lie  in  their 
differing  abilities  to  implement  the  additional  countermeasures 
imposed  by  this  considerably  more  demanding  environment. 


4.1.1  The  Data  Security  Problem 

The  data  security  problem  can  be  defined  in  terms  of  the  secu¬ 
rity  threats  that  must  be  countered  by  a  command  center  local  area 
network.  In  discussing  these  threats,  comparisons  are  made  between 
cable  bus  countermeasures  and  message  switch  countermeasures  in  order 
to  point  out  the  potential  advantages  and  disadvantages  of  each.  At 
a  minimum,  one  would  desire  that  the  cable  bus  system  would  afford  at 
least  as  much  data  security  as  the  message  switch. 

There  are  a  large  number  of  potential  threats  to  data  security, 
many  of  which  apply  only  in  the  broadest  sense  to  communications  pro¬ 
cessors.  In  many  instances  the  appropriate  countermeasures  are 
entirely  unrelated  to  the  particular  inplementation.  For  example, 
countering  physical  theft  of  data  by  a  trusted  person  from  within  a 
facility  is  entirely  a  matter  of  physical  and  administrative  safe¬ 
guards  such  as  inspection  of  materials  leaving  the  site  and  indivi¬ 
dual  clearances.  Thus,  threats  such  as  penetration  of  a  facility  by 
an  overwhelming  force  and  threats  related  to  administrative  counter¬ 
measures  such  as  periods  processing,  guarded  restart  procedures  and 
system  high  personnel  clearance  are  seen  as  equally  applicable  to 
both  the  cable  bus  and  message  switch.  These  threats  are  mentioned 
here  and  in  the  sections  that  follow  as  a  baseline  security  policy 
with  little  or  no  further  comment.  More  complete  discussions  of 
these  threats  and  countermeasures  are  contained  in  Courtney and 
MSA.  While  it  can  never  be  demonstrated  that  a  particular  list  of 
threats  in  a  given  environment  is  complete,  an  attempt  has  been  made 
to  deal  with  the  perceived  major  threats  to  the  cable  bus  and  message 
switch  systems.  Table  I  is  a  capsule  description  of  the  remaining 
threats  that  must  be  effectively  countered  by  both  the  cable  bus  and 
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•lISfwrriK  Moadet  of  properly  prcfwroil  message  in  the  clear  is  acciden¬ 
tally  chanqed  during  transmission  so  that  the  address  or  authorization 
information  is  incorrect 

.sriLlAGr  Misappl ication  of  autliorization  or  occidental  apjxjndoqe  of 
parts  of  one  message  to  another 

fARPLiric;  FAimnKS  System  errors  which  cause  incorrect  or  missing  clas¬ 
sification  or  con;\3rtuent  indicators 


irrrF7moNAL  threats 

£1  Cutting  communications  lines  or  other  viol  i berate 


I?  1 1T1A1  m ton T 7. ED  SYSTT?!  ACCESS  An  outsider  with  a  legitimate  terminal  or 

other  moans,  or  by  an  insider's  violation  of  authorization  level,  nced- 
to-know  or  community  of  interest 

n  ^lAriATIOUP  Interception  or  analysis  or  stray  electronic  signals  used  to 
acquire  information  directly  or  through  traffic  analysis;  if  message 
lengths,  sources  and  destinations,  traffic  volumes  and  flow  patterns  arc 
discernible,  useful  information  may  l*e  gained  without  message  contents 

14  rroniiXT,  The  introduct ion  of  spurious  command  sequences  in  an  attempt  to 
drive  software  into  unknown  or  untested  states  which  may  alien/  unautlior- 
ized  access 

15  SPOOriPT.  Various  masquerading  ttchin  mes  allowing  attacker  to  take  on 
rights  of  Uqitinato  user 

PLAYRAC;  Repetition  of  rocora^i  command  sequences  to  acquire  access 

16  !JI3BEflSC£3A3LE  snTVjCC  DITwln  Total  consumption  of  avail  sole  resources; 
overloading 

T7  ADVAXP.  ?LAirri:iG  Previously  .Planted  device:-  (Trojan  horse,  trap  viooi , 
timo-honbrd  tri'MoroJ  ’.•'v  outside  si  anal  or  event  sequence  oa  oiondar 
event  allowing  access  or  service  denia  l 
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message  switch.  Data  security  threats  may  be  divided  into  two 
categories,  accidental  and  intentional.  The  accidental  threats  are 
labeled  as  A1  and  A2.  The  intentional  threats  are  labeled  II  through 
17.  (These  labels  are  used  in  Table  II  to  refer  to  specific 
threats.) 

4.1.2  The  Evolving  WWMCCS  Security  Environment 

The  command  center  security  model  of  today  is  a  single-level 
mainframe  attached  to  a  single-level  long  haul  network.  Over  the 
next  decade  the  WWMCCS  security  policy  will  evolve  from  this  rela¬ 
tively  simple  single-level,  system-high  policy  to  more  complex  secu¬ 
rity  policies  involving  mixed  single-level  entities  and  eventually  to 
a  full  multi-level  security  policy. 

In  the  present  sinple  model,  physical  and  administrative  pro¬ 
cedures  can  insure  the  integrity  of  the  environment.  As  the  transi¬ 
tion  to  a  multi-level  security  policy  occurs,  sophisticated  software 
validation  techniques  and  encryption  methods  are  of  paramount  inpor- 
tance. 

The  ensuing  sections  explore  the  WTO1CCS  security  policy  evolu¬ 
tion  in  incremental  steps.  At  each  stage,  for  both  the  cable  bus  and 
message  switch  systems,  a  determination  is  made  of  the  requisite 
security  countermeasures  and  an  assessment  is  made  of  the  relative 
ease  of  implementation  of  these  countermeasures.  This  assessment 
demonstrates  that  the  distributed  nature  of  the  cable  bus  does  not 
preclude  the  effective  use  of  classical  physical  containment  security 
methods,  and  moreover,  has  a  favorable  effect  on  the  implementation 
of  the  more  sophisticated  ADP  countermeasures. 

4. 1.2.1  The  Present  Security  Environment.  Present  day  command 
center  security  measures  rely  largely  upon  physical  and  administra¬ 
tive  steps  to  contain  command  center  components.  These  steps  include 
clearing  all  personnel  to  a  system-high  security  level  and  placing 
components  within  a  limited  access  vault. 
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TABLE  II 


EVOLVING  WWMCCS  COMMAND  CENTER  SECURITY  CONSIDERATIONS 

PRESENT  ENVIRONMENT 

WWMGCS  Mainframes  Connected  To  Single-Level  Long-Haul  Network 

Ccun  JERMEASURES 

MESSAGE  SWITCH  CABLE  BUS 

Entire  system  within 
secure  vault  [11,13] 

System  high  operation  [A1,I4] 

Remote  access  by  name/password  [12] 

Separation  of  commands  and  data 
by  making  message  switch  or 
interface  unit  non-programmable  [14,16] 

System  limitation  on  resource  usage 
by  operating  system  by  contention,  guarded 

scheduling  algorithm  [16]  with  watchdog  timer  [A2,I6] 


each  device  on 
individual  line  [A2] 


TABLE  II  (Continued) 


M ID-1982  ENVIRONMENT 

Interconnection  Via  Multi-Level  Secure  Long-Haul  Network 
(AUTODIN  II)  With  Hosts  And  Terminals  At  Different  Single  Levels 


COUNTERMEASURES 

MESSAGE  SWITCH  CABLE  BUS 

Individual  Authentication  [12] 

in  hosts  and  message  switch  in  hosts  and  interface  units 

Device  Authentication  [12,15] 

kernel  mediates  transfers  interface  units  tailored 

between  different  devices  to  device  (modular, 

(complex  software)  simple  software) 

Verified  software  in  message  Verified  address  detection 

switch  [A1,I4,I7]  (difficult  software  in  interface  units 
for  large  amounts  of  code)  [Al, 14,17]  (reasonable 

for  small  amounts  of  code) 

Security  level  and  Security  level  and 

compartment  check  in  compartment  check  in 

message  switch  [A1,I4]  interface  units  [A1,I4] 

Monitoring  and  auditing  by  Monitoring  and  auditing  by 

kernel  reported  to  security  control  point  on  cable  bus 

officer  [12.14]  reported  to  security 

officer  [12,14] 

Replication  of  fields,  fixed 
message  sizes,  cyclic 
redundancy  checks  [A1,I3] 

Encryption  hardware  and 
fixed  key  distribution 
[Al, 13, 14, 15] 

Device  connection  monitor  to 
detect  failures,  connections 
disconnects  [A2, 13, 14, 16] 


TABLE  II  (Concluded) 


1985-1987  ENVIRONMENT 
Addition  of  Multi-Level  Hosts 


COUNTERMEASURES 


MESSAGE  SWITCH 


CABLE  BUS 


End-to-end  encryption 
and  expanded  access 
control  techniques 
[Al, 13, 14, 15] 


Encryption  with  PKD  or 
other  dynamic  key 
distribution  [Al, 13, 14, 15] 


Verified  software  in 
interface  unit  [A1,I4,I7] 
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The  message  switch  mainframe  is  one  of  the  components  that  would 
be  installed  within  the  vault.  Figure  8  depicts  this  architecture. 
The  vault  prevents  unauthorized  physical  access  thereby  preventing 
the  introduction  of  specialized  equipment  or  use  of  existing  equip¬ 
ment  by  unauthorized  personnel.  To  an  extent,  it  also  prevents  ema¬ 
nations  due  to  the  shielding  of  the  vault.  Other  emanating  equipment 
also  installed  in  the  vault  usually  prevents  recognition  of  message 
switcn  emanations.  ADP  security  measures  are  rather  limited 
currently.  Attempts  are  made  to  test  hardware  and  software  to  demon¬ 
strate  correct  operation  under  both  expected  and  unexpected  cir¬ 
cumstances.  Certain  denial  of  service  threats  are  moderated  or 
defeated  by  operating  system  scheduling  algorithms  which  attempt  to 
distribute  system  resources  equitably.  Simple  password  mechanisms 
are  usually  employed  to  provide  individual  authorization.  Addition¬ 
ally,  the  message  switch  operating  system  can  be  configured  to  allow 
no  user  programming  which  aids  in  preventing  some  probing  attacks. 

The  cable  bus  backbone  must  also  be  protected  from  physical 
attack  by  installation  in  some  form  of  protected  environment.  If,  as 
shown  in  Figure  9,  the  cable  bus  backbone  and  all  interface  units  are 
similarly  protected  by  a  vault,  all  message  switch  physical  security 
measures  apply.  An  additional  component  in  each  interface  unit, 
known  as  a  watchdog  timer,  inhibits  a  failed  interface  unit  from 
denying  service  to  other  interface  units  by  continuous  transmission. 
If  an  interface  unit  has  been  continuously  transmitting  for  an 
extended  time,  the  watchdog  timer  disables  the  interface  unit.  The 
interface  unit  is  not  a  user  programmable  device,  so  it  is  not  sub¬ 
ject  to  being  used  in  probing  attacks.  The  current  interface  unit 
has  been  subjected  to  TEMPEST  emanation  testing. 

The  variable  length  of  a  cable  bus  backbone  allows  it  to  expand 
or  contract  to  meet  a  variety  of  physical  considerations.  On  one 
hand,  one  might  envision  a  very  short  cable  backbone,  on  the  order  of 
five  or  ten  feet,  which  connects  interface  units  which  have  been 
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Concentrated  in  a  very  local  area.  This  architecture  is  shown  in 
Figure  10.  The  communications  lines  terminated  by  these  interface 
units  are  the  same  lines  that  would  be  terminated  by  a  cabinet  con¬ 
taining  a  message  switch  mainframe.  Thus  by  physically  installing 
the  cable  bus  in  a  vault  the  cable  bus  can  be  as  physically  secure  as 
the  message  switch.  On  the  other  hand,  a  longer  backbone,  as  shown 
in  Figure  11  may  be  desirable.  If  this  is  the  case,  the  backbone  may 
be  extended  to  be  physically  closer  to  command  center  components  pos¬ 
sibly  increasing  the  reliability  of  the  component  to  interface  unit 
transmissions  and  possibly  easing  the  addition  of  new  equipment. 

It  is  expected  that  single-level  secure  mainframes  and  many  of 
their  physical  and  administrative  security  measures  will  continue  to 
be  a  part  of  the  command  center  environment  for  the  foreseeable 
future. 

4. 1.2. 2  The  Environment  of  the  Earlv-80's.  It  is  felt  that 
sometime  in  mid-1982  or,  possibly  later,  a  multi-level  secure  NFE 
providing  access  to  the  AUTCDIN  II  network  will  be  available.  The 
NFE  and  AUTCDIN  II  multi-level  data  handling  capabilities  will  neces¬ 
sitate  a  requirement  for  handling  single  level  terminals  and  comput¬ 
ers  which  are  not  necessarily  all  cleared  to  a  system  high  security 
level;  some  terminals  may  access  the  AUTCDIN  II  network  at  a  confi¬ 
dential  level  while  sane  mainframes  are  operating  locally  at  top 
secret.  In  this  architecture,  not  all  personnel,  terminals  and  com¬ 
puters  are  necessarily  cleared  to  the  highest  security  level.  Thus, 
ADP  measures  must  be  inplemented  in  both  the  cable  bus  and  message 
switch  to  provide  separation  of  sensitive  data  streams. 

Because  the  message  switch  terminates  all  terminal  and  computer 
communication  lines,  a  security  kernel  or  kernel-like  executive  is 
needed  to  mediate  invocations  of  the  different  communications  line 
software  modules.  To  insure  that  this  mediation  is  correct  and  fair, 
the  kernel  software  must  be  formally  verified.  The  executive  in  turn 


provides  support  for  other  software  modules  that  actually  inplement 
message  switching  functions:  routing  of  data  from  one  communication 
line  to  another;  checking  the  security  level  of  a  message  to  deter¬ 
mine  whether  it  may  be  routed  to  a  second  communication  line;  and 
implementing  individual  authentication  in  the  form  of  a  usercode  and 
password.  To  insure  that  multi-level  data  is  handled  correctly,  the 
message  switch  specific  software  modules  must  also  be  formally  veri¬ 
fied.  As  a  part  of  the  verified  software,  monitoring  and  auditing 
functions  may  be  employed  to  report  attempted  violations  to  a  secu¬ 
rity  officer  for  further  action. 

Separation  of  multi-level  data  streams  may  be  enforced  somewhat 
differently  in  the  cable  bus  architecture.  Since  each  interface  unit 
terminates  one  or  two  communication  lines,  each  unit  may  still  be 
operated  at  a  single  level.  This  means  that  only  address  detection 
and  security  level  checking  software  must  be  verified.  Address 
detection  software  monitors  messages  on  the  cable  bus  backbone  to 
determine  when  one  is  addressed  to  the  local  interface  unit.  The 
amount  of  interface  unit  software  to  be  verified  is  significantly 
less  than  that  required  in  the  message  switch.  While  each  interface 
unit  only  handles  messages  at  a  single  security  level,  the.  cable 
backbone  transports  messages  of  varying  levels.  To  separate  data 
streams  and  provide  protection  against  analysis  of  messages  and 
traffic  on  the  backbone,  data  encryption  may  be  used  to  encode  back¬ 
bone  message  header  and  data  information.  While  formal  software 
verification  and  end-to-end  data  encryption  technologies  are  both  in 
early  stages  of  development,  it  appears  that  during  the  next  3-5  year 
term,  encryption  hardware  will  be  available  to  provide  a  greater 
level  of  confidence  with  higher  overall  performance  than  formal 
verification  of  kernel  software.  Integrated  circuits,  which  operate 
at  or  above  cable  bus  backbone  speeds,  are  now  available  to  irrplement 
the  Data  Encryption  Standard. Stronger  encryption  methods,  such 
as  the  Public  Key  Distribution  method,  will  enable  dynamic  key  modif- 
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ication  over  much  shorter  timeframes.  Thus,  the  cable  bus  trades 
formal  verification  of  all  software  for  partial  verification  and 
encryption  to  accomplish  the  same  effective  data  security. 

When  encryption  is  used,  it  is  unlikely  that  a  message  damaged 
in  transit  will  decrypt  to  anything  sensible,  but  if  a  legitimate 
address  is  produced,  the  verified  address  detection  software  is  the 
first-level  defense  against  misdelivery  of  messages.  As  secondary 
protections  against  misdelivery,  a  cyclic  redundancy  check  (CRC)  may 
be  used  and  address  and  security  level  fields  may  be  replicated  in 
message  headers.  After  decryption,  the  CRC  can  be  recalculated  and 
the  contents  of  the  replicated  fields  can  be  compared.  In  the 
unlikely  event  that  a  message  is  damaged  and  not  detected  through 
encryption,  these  additional  mechanisms  will  insure  against  misrout- 
ing. 

The  cable  bus  must  also  irrplement  monitoring  and  auditing 
software  and  hardware  to  report  attempted  security  violations.  In 
the  cable  bus,  this  takes  the  form  of  a  continuity  detection  circuit 
and  individual  authentication  software.  The  continuity  circuit 
reports  any  changes  in  the  continuity  of  the  cable  bus  backbone  and 
attached  interface  units.  The  continuity  circuit  may  be  inplemented 
by  measuring  resistance,  capacitance,  or  voltage  changes  on  the  cable 
bus  backbone.  The  individual  authentication  software  is  driven  by 
security  level  checking  and  login  procedures  which  verify  an  indivi¬ 
duals  security  level  clearance. 

Since  all  messages  on  the  backbone  will  be  encrypted  at  some 
point  in  the  future  it  is  not  unreasonable  to  expect  that  interface 
units,  placed  in  hardened  enclosures,  can  be  located  outside  of  the 
vault.  This  arrangement  is  depicted  in  Figure  12. 

The  coaxial  cable  connecting  the  interface  unit  to  the  backbone 
is  subject  to  physical  attack.  If  this  line  is  cut,  it  should  be 
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FIGURE  12 

ALTERNATE  SECURE  CABLE  BUS 


made  clear  that  only  communications  with  the  remote  interface  unit 
are  disrupted.  The  main  backbone  continues  to  function. 

4. 1.2. 3  The  Environment  of  the  Mid-80's.  It  is  expected  that 
sometime  in  the  mid-1980's  the  introduction  of  multi-level  secure 
mainframes  based  on  approaches  such  as  KVM  will  necessitate  the 
requirement  for  multi-level  security  throughout  the  command  center. 

Since  the  message  switch  was  already  required  to  handle  data 
streams  at  differing  levels  of  security  no  further  software  functions 
are  required. 

If  mainframes  support  multi-level  data  streams,  cable  bus  inter¬ 
face  units  may  at  any  one  time  have  messages  of  varying  security  lev¬ 
els  within  them.  This  means  that  software  other  than  address  detec¬ 
tion  and  security  level  validation  modules  must  be  verified.  It  is 
believea  that  the  same  sofware  constructs  used  to  provide  verified 
separation  of  message  switch  data  streams  will  be  directly  applicable 
to  the  interface  unit. 

It  is  felt  that  stronger  encryption  algorithms,  using  a  Public 
Key  algorithm  will  be  available  by  this  time  in  hardware  form.  The 
addition  of  stronger  encryption  methods  will  make  it  possible  to  per¬ 
form  user  authentication  via  interface  unit  and,  if  it  makes  sense,  a 
central  username/password  facility. 

4. 1.2. 4  The  Environment  of  the  Late-80's.  in  the  late  1980's 
the  first  components  of  the  next  generation  of  the  WWMCCS  Information 
System  will  begin  to  appear  in  operational  command  centers.  These 
components  will  include  newer  WWMCCS  mainframes  as  well  as  special¬ 
ized  functional  elements  such  as  teleconferencing  and  data  base  han¬ 
dling  mainframes. 

The  loading  induced  by  the  secure  handling  from  these  systems 
will  non-linearly  increase  the  complexity  of  the  message  switch, 
resulting  in  steadily  decreasing  performance  and  the  real  possibility 
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of  overload  failure,  increased  difficulty  in  maintenance  of  the 
software  and  the  prospect  of  reverification  of  sizable  amounts  of 
software  with  the  addition  of  each  new  device. 

The  multi-level  secure  interface  unit,  on  the  other  hand,  will 
not  degrade  as  various  components  are  added  to  the  command  center. 
Each  additional  component  adds  an  interface  unit  to  provide  interface 
buffer  capacity  and  protocol  processing  cycles.  The  increased  load 
will  in  turn  increase  traffic  on  the  cable  bus  backbone.  However, 
the  application  of  backbone  technologies  such  as  fiber  optic  bundles 
which  support  gigabit  transfer  rates  should  reasonably  support  com¬ 
mand  center  requirements. 

4.1.3  Security  Conclusions 

It  is  proper  to  point  out  here  that  until  a  detailed  design,  and 
in  some  cases  actual  implementation,  is  completed,  some  of  the  propo¬ 
sals  and  extrapolations  presented  here  must  necessarily  be  regarded 
as  speculative.  It  is  certainly  the  case  that  before  recommending 
establishment  of  a  cable  bus  system  in  a  command  center,  careful 
experimentation  and  testing  needs  to  be  carried  out.  In  fact,  no 
local  area  network  architecture  can  solve  the  data  security  problem 
in  the  general  sense  since  it  must  interact  with  other  elements 
(e.g.,  host  computers  with  outdated  operating  systems,  communications 
links  to  other  systems)  whose  deficiencies  will  not  disappear  with 
the  installation  of  a  cable  bus  or  other  local  communications  systan. 
The  intention  was  to  determine  the  affect  of  a  cable  bus  on  the 
overall  system.  It  is  believed  that  the  foregoing  discussion  demon¬ 
strates  that  the  cable  bus  will  be  at  least  as  secure  as  the  message 
switch  architecture. 

Thus,  the  cable  bus  may  employ  security  measures  at  least  as 
strong  as  the  message  switch.  Furthermore,  despite  the  physical  lim¬ 
itations  on  the  layout  of  the  interface  units,  the  cable  bus  provides 
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a  flexible  interconnection  architecture  superior  to  the  centrally 
located  message  switch  mainframe. 

4.2  Functionality 

The  centralized  message  switch  and  distributed  cable  bus  archi¬ 
tectures  both  provide  local  terminal-to-computer  and  computer-to- 
computer  communications  functions.  A  distinction  between  the  archi¬ 
tectures  lies  in  a  potentially  larger  cable  bus  bandwidth  for  sup¬ 
porting  computer-to-computer  communications.  Coaxial  cable 
bandwidths  are  bounded  by  the  effective  electrical  bandwidth  of  the 
wire,  295M  Hz  in  the  MITRE  systsn.  Message  switch  bandwidths  are 
bounded  by  the  speed  at  which  software  can  route  messages  from  input 
interface  to  output  interface.  This  bound  is  naturally  message 
switcn  hardware  and  software  dependent.  Effective  cable  bus  and  mes¬ 
sage  switch  bandwidth  is  determined  largely  by  buffering  capacity  and 
the  arrival  rate  of  "to-be-transmitted"  messages.  Hie  cable  bus 
buffering  capacity  is  the  the  sum  of  the  buffering  capacity  of  all 
interface  units.  The  message  switch  buffering  capacity  is  the  amount 
of  main  message  switch  memory  dedicated  to  buffering.  The  number  of 
cable  bus  processor  cycles  is  the  aggregate  sum  of  all  of  the  inter¬ 
face  unit  processor  cycles.  The  message  switch  is  limited  to  the 
number  of  message  switch  processor  cycles. 

The  cable  bus  has  an  inherent  broadcast  capability  not  available 
in  the  message  switch  since  all  interface  units  "see"  each  message. 
The  introduction  of  name  tables  inplemented  in  an  associative  memory 
allows  interface  units  to  be  treated  as  groups  for  broadcast 
transmissions.  The  message  switch  must  replicate  and  transmit  each 
broadcast  message  for  each  communication  line  which  is  to  receive  the 
information.  This  broadcast  capability  is  potentially  useful  in 
implementations  including  teleconferencing. 

The  MITRE  cable  bus  system  is  unique  among  cable  bus  systems  in 
that  it  uses  radio  frequency  modems  to  transport  digital  information 
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via  frequency  division  multiplexing.  This  offers  the  capability  to 
transmit  video  and  audio  signals  along  with  digital  information  on 
the  same  wire.  Finally,  this  radio  frequency  transmission  technique 
enables  the  creation  of  several  logically  distinct  network  systems 
using  the  same  wire.  The  interface  units  can  be  "tuned"  to  the 
appropriate  digital  network.  This  lends  itself  to  the  transmission 
of  information  at  differing  security  levels  on  different  frequencies 
of  the  same  cable. 

4.3  Reliability 

A  system  is  reliable  when  it  operates  correctly  for  a  length  of 
time  which  is  satisfactory  to  a  large  percentage  of  its  users.  Reli¬ 
ability  is  measured  in  terms  of  the  average  number  hours  between 
failure.  Failures  result  from  both  software  and  hardware  induced 
errors.  System  reliability  is  difficult,  if  not  impossible,  to  meas¬ 
ure,  without  direct  experience  with  the  system.  Software  failure 
rates  are  dependent  on  the  quality  of  the  initial  inplementation  and 
the  quality  of  software  maintenance  personnel;  fixing  one  software 
failure  may  uncover  or  induce  other  failures.  The  reliability  of 
hardware  logic  devices  is  also  difficult  to  measure  effectively. 
Computer  systems  use  such  a  large  number  of  components  (from  100  to 
1,000,000  devices)  that  device  reliability  must  be  at  least  as  good 
as  10  ®  failures  per  hour  to  be  useful.  It  is  not  hard  to  test  to 
this  level.  However,  testing  to  10  ^  becomes  very  expensive  in  pro¬ 
duction  numbers,  primarily  because  of  the  length  of  the  test.  Newer 
more  capable  devices  are  being  produced  at  such  a  rapid  rate  that  it 

is  not  cost  effective  for  manufacturers  to  demonstrate  reliability  of 
”6  “7 

10  to  10  failures  per  hour  even  though  true  reliability  may  be 
better.  Thus,  measurement  of  operational  prototype  system  is 
required  to  determine  reliablity.  Since  neither  the  NFE  nor  MITRE 
cable  bus  systems  are  operational,  a  message  switch/cable  bus  relia¬ 
bility  comparison  is  limited  to  a  discussion  of  architectural 
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weaknesses  which  would  make  one  or  the  other  architectures  inherently 
less  reliable. 

The  major  architectural  weakness  of  the  message  switch  is  clear: 
a  single  point  message  switch  failure  will  take  down  the  whole  com¬ 
mand  center  communications  backbone.  The  message  switch  may  also 
fail  in  overload  situations  by  denying  users  service  during  what  may 
be  a  crisis.  Protection  against  these  failures  is  usually  imple¬ 
mented  in  the  form  of  redundant  systems.  This  is  expensive  since  the 
message  switch  and  its  interconnections  with  other  components  must  be 
replicated.  Other  approaches  to  nearly  redundant  systems  are  typi¬ 
fied  by  Pluribus^14^  and  TELENET  TP4000^15^  which  may  offer  signifi¬ 
cant  improvement. 

The  cable  bus  architecture  does  not  suffer  from  this  particular 
malaay.  Each  of  the  interface  units  are  passive  devices  whose  only 
cable  bus  wide  failure  mode,  continuous  transmission,  can  be  pro¬ 
tected  against  by  a  simple,  inexpensive  watchdog  timer  which  disables 
an  interface  unit  if  it  has  been  continuously  transmitting  for  an 
extended  period  of  time.  The  cable  bus,  because  it  uses  a  single 
wire,  is  also  subject  to  overload.  Here  redundancy  is  also  a  solu¬ 
tion,  in  the  form  of  second,  or  third  cable  bus  communication  back¬ 
bones  which  are  inexpensive.  The  MITRE  system  is  particularly  amen¬ 
able  to  this  because  of  its  use  of  radio  frequency  to  carry  digital 
data.  To  move  an  interface  unit  from  one  "logical"  cable  backbone  to 
another  is  a  matter  of  tuning  interface  unit  modems  to  a  different 
channel . 

Finally,  the  physical  separation  of  interface  units  prevents  a 
failure  in  one  unit  from  affecting  the  operation  of  another  unit.  A 
bug  in  one  interface  unit  software  will  not  damage  the  tables  or  data 
of  another  interface  unit.  Thus,  development  of  newer  software  may 
even  reasonably  take  place  alongside  operational  units.  This  is  very 
difficult  to  do  in  the  message  switch  environment. 
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4.4  Cost 


An  attempt  has  been  made  to  determine,  as  accurately  as  possi¬ 
ble,  the  predicted  fixed  and  recurring  costs  of  a  cable  bus  system 
and  a  comparable  message  switch  configuration.  For  the  purposes  of 
comparison,  recurring  costs  are  estimated  over  a  10  year  life  cycle. 
There  are  a  number  of  overall  system  components  which  are  common  to 
both  systems  which  are  not  included  in  this  comparison  such  as  com¬ 
munications  lines  and  packet  switch  specific  software. 

4.4.1  Cable  Bus 

The  cost  of  a  cable  bus  is  primarily  incurred  in  the  acquisition 
of  its  two  major  component  groups:  (1)  the  cable  backbone,  and  (2) 
the  interface  units. 

4. 4. 1.1  Cable  Backbone.  Since  standard  CA1V  components  are 
used,  the  cost  of  a  cable  backbone  is  well  known  and  minimal.  The 
components  are: 


Headend 

$1000 

Cable  at  $500/mile 

750 

Splitters  at  $25 

250 

Taps  at  $9 

270 

Miscellaneous 

_ 2 20. 

Total  $2500 

The  $2500  cable  backbone  shown  above  is  for  a  system  covering 
approximately  1/2  mile.  Components  are  included  to  branch  the  cable 
10  times  to  conform  to  building  architecture  and  tap  into  the  cable 
at  30  locations;  each  tap  can  support  one  to  four  interface  units 
Other  one  time  purchase  installation  equipment  (spectrum  analyzer, 
field  strength  meter)  may  run  as  high  as  $5000. 

4. 4. 1.2  Interface  Units.  The  interface  units  utilized  in  the 
MITRE  Washington  test  bed  are  hand-built,  wire-wrapped  circuit  boards 
costing  $1000  per  unit.  The  units  are  constructed  with  older,  inex¬ 
pensive  MOS  technology  and  Motorola  components.  Commercially 
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available  units  using  newer  Zilog  components  are  being  manufactured 
at  a  cost  of  $1500  per  unit.  Both  units  provide  the  same  capabili¬ 
ties,  and  consequently,  are  not  capable  of  supporting  WW40CS  Command 
Center  security  and  offloaded  protocol  requirements. 

From  the  work  described  in  this  report,  a  set  of  components  for 
an  interface  unit  capable  of  supporting  WWMCCS  command  center  commun¬ 
ication  requirements  has  evolved.  Estimated  prices  for  those  com¬ 
ponents  are  shewn  below: 


1979 

1982 

64K  bytes  RAM/RCM 

$550 

$250 

RF  Modems 

300 

300 

Power  Supply 

100 

100 

Name  Table 

150 

25 

CPU 

120 

100 

Encryption 

100 

80 

DMA  Interface  Circuits 

80 

80 

Cable  Transmit  Watchdog 

25 

10 

Clock  Timer 

20 

20 

Mi sc.  (Cabinet, 

Connectors) 

355 

225. 

Totals 

1800 

1200 

The  estimates  shown  in  the  first  column  above  give  1979  costs 
for  the  commercial  construction  of  a  WWMCCS  capable  bus  interface 
unit.  The  estimates  were  obtained  by  taking  the  list  prices  for 
existing  integrated  circuits  and  adjusting  the  value  upward  to 
account  for  assembly  of  the  component  into  the  interface  unit.  The 
prices  include  no  figures  for  profit,  overhead,  or  recovery  of 
development  costs. 

The  price  of  memory  represents  almost  1/3  of  the  total  cost  of 
the  unit.  The  memory  was  sized  at  48K  bytes  of  RAM  and  16K  bytes  of 
EPRCM.  It  is  believed  that  this  is  significantly  more  memory  than 
will  actually  be  needed. 


The  second  column  above  gives  an  estimate  of  the  1982  commercial 
cost  of  the  same  interface  unit,  taking  into  account  the  kinds  of 
decreases  in  price  that  have  been  seen  over  the  past  three  years. 
Memory  in  particular  has  been  rapidly  decreasing  in  cost  in  recent 
years.  The  price  decrease  of  RAM  and  CCD  memory  circuits  over  the 
past  seven  years  in  cents/bit  is  shown  in  Figure  13.  The  price  per 
bit  in  1976  was  approximately  0.2  cents/bit.  The  price  per  bit  at 
the  beginning  of  1979  is  shown  as  0.07  cents  per  bit.  Now,  towards 
the  end  of  19/9,  the  actual  cost  per  bit  is  closer  to  0.035.  Digital 
Equipment  Corporation,  for  example,  has  decreased  its  price  for  an 
LSI-11  64K  byte  RAM  two  times  this  year  alone,  from  $1149  to  $774  to 
$582.  If  the  price  trends  shown  in  Figure  13  hold  as  expected,  a 
cost  of  0.02  cents/bit  can  be  projected  for  mid-1981,  resulting  in 
the  interface  unit  memory  estimate  of  approximately  $250. 

The  power  supply  also  represents  a  significant  element  of  the 
cost.  This  cost  could  be  reduced  significantly  by  integrating  the 
interface  unit  circuit  boards  directly  into  the  chassis  of  newer  ter¬ 
minals,  thereby  allowing  for  a  sharing  of  the  terminal  power  supply. 

Although  the  advantages  of  employing  RF  modems  discussed  else¬ 
where  would  be  sacrificed,  base-band  signalling  techniques  could  be 
used  for  which  nothing  comparable  to  a  modem  is  required.  The  elimi¬ 
nation  of  the  RF  modem  could  reduce  the  1982  estimate  by  25  per 
cent. 

Based  on  the  estimates  outlined  above,  the  cost  of  a  cable  bus 
system  is  largely  dependent  upon  the  number  of  its  interface  units. 
Each  interface  unit  will  support  one  high  speed  computer  interface  or 
from  one  to  four  terminal  interfaces,  depending  on  the  type  and  com¬ 
plexity  of  the  terminal.  For  the  purposes  of  this  repert,  it  is 
estimated  than  an  average  of  two  terminals  will  be  supported  by  each 
interface  unit.  The  cable  bus  system  fixed  cost,  C,  as  a  function  of 
the  number  of  attached  computers  and  terminals  is: 


Source:  Dave  House,  "CCD  vs.  RAM  for  Bulk  Storage 
Applications,"  Digest  of  Papers,  COMPCON  Spring  76 
San  Francisco,  Calif.,  p.  60. 


FIGURE  13 

MEMORY  COST-CENTS/BIT 


C(#Comp,  #Term)  =  #Comp  *  $1800  +  #Term  *  $900  +  $2500 


Recurring  cable  bus  maintenance  costs  are  difficult  to  estimate. 
The  maintenance  policy  for  interface  units  is  similar  to  the  typical 
terminal  maintenance  procedure  which  is  to  handle  malfunctions  by 
swapping  spare  circuit  boards  into  the  unit  until  operation  is 
restored.  Therefore,  maintenance  costs  are  estimated  by  supplying 
two  spare  interface  units  for  each  cable  bus  installation  and  provid¬ 
ing  a  service  for  the  repair  of  damaged  interface  units.  It  is 
estimated  that  each  interface  unit  will  require  repair  five  times 
over  a  ten  year  period  and  that  each  repair  will  cost  approximately 
four  percent  of  the  unit,  or  $75.  Thus,  a  recurring  cable  bus  cost 
of  $12,600  for  each  cable  bus  system  is  estimated. 

4.4.2  Message  Switch  Cost 

The  cost  of  a  message  switch  is  incurred  in  the  acquisition  of 
computer  interfacing  hardware,  terminal  interfacing  hardware,  and  a 
cpu  to  support  movement  of  data  between  interface  communication 
lines.  Message  switch  cost  is  estimated  by  extracting  message 
switcning  hardware  costs  from  NFE  cost  estimates;  ignored  here  are 
the  costs  associated  solely  with  its  front  end  functions.  This  esti¬ 
mate  includes  NFE  computer  interfaces,  NFE  terminal  interfaces  and  a 
percentage  of  NFE  cpu  costs. 

The  cost  of  a  network  front  end  implemented  on  six  alternative 
hardware  bases  is  estimated  in  a  Digital  Technology  incorporated 
(DTI)  report. The  average  price  of  these  systems  is  $95,130.  The 
average  price  of  the  terminal  interfacing  hardware  is  $18,362.  This 
hardware  interfaces  32  terminal  lines  to  the  NFE.  From  the  DTI 
report  an  estimate  of  the  memory  required  to  support  32  terminals  may 
be  derived: 


Code 

Buffers 

Total 


15.3K  bytes 
167. 2K  bvtes 
182.5K  bytes 

The  total  amount  of  memory  recommended  is  512K  bytes.  The  ter¬ 
minal  handling  memory  may  then  be  roughly  estimated  at  35  per  cent  of 
the  overall  NFE  memory  requirements.  It  is  also  estimated  that  as 
many  as  half  of  the  NFE  processing  cycles  will  be  exposed  at  any  one 
time  to  handling  character-at-a-time  or  block-at-a-time  interrupts 
from  directly  connected  front  end  terminals.  Based  on  these  admit¬ 
tedly  rough  estimates  and  direct  experience  with  NFE  measurements,  a 
conservative  measure  of  25  per  cent  of  the  NFE  as  a  whole  may  be 
attributed  to  terminal  handling.  Thus,  25  per  cent  of  the  NFE  cpu 
cost,  $19,192,  may  be  directly  attributed  to  message  switching. 

The  cost  of  providing  a  high-speed  direct  memory  access  inter¬ 
face  between  the  message  switch  and  computer  components  is  estimated 
from  the  DTI  report  at  $2000  per  interface. 

The  total  fixed  message  switch  cost  is  then  estimated  as: 


$19,192 (cpu)  +  $18,362 (term)  +  $2000  *  7(comp)  =  $51,554 

The  average  recurring  monthly  maintenance  for  the  six  systems 
described  in  the  DTI  report  is  $941.  Taking  the  estimated  25  per 
cent  yields  a  monthly  message  switch  maintenance  figure  of  $235.25. 

4.4.3  Cable  Bus  -  Message  Switch  Cost  Comparison 

The  comparison  then  between  the  projected  cable  bus  costs  and 
the  derived  message  switching  costs  is  relatively  straightforward. 

The  cost  of  a  command  center  local  area  network  with  32  termi¬ 
nals  and  8  larger  computer  components  may  be  computed  for  the  cable 
bus  and  the  message  switch. 


Cable  bus  costs  are  computed  via  the  cable  bus  cost  formula: 


C(8,32)  =  8*$1800  +  32*$900  +  $2500  =  $45,700 

Message  switch  costs  were  derived  above: 

$19,192  +  $18,362  +  $14,000  =  $51,554 

Added  to  these  fixed  costs  are  recurring  maintenance  expenses 
over  a  10  year  life  cycle. 

Cable  bus: 

Spare  interface  units 
Repair  service 

Total 

Message  Switch: 

$235.25  *  120mo  =  $28,230 

Given  that  WWMCCS  installs  these  systems  at  the  23  sites  where 
NFE  installations  are  planned,  the  comparative  costs  for  the  message 
switcn  and  cable  bus  are: 


$3600 

$9000 

$12,600 


Cable  bus: 

$1,051,100 
$  289, m 
$1,340,900 


Fixed  Cost  at  $45,700 
Recurring  at  $12,600 

Total 


Message  Switcn: 

Fixed  Cost  at  $51,554 
Recurring  at  $28,230 

Total 


$1,185,742 

fnM 
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Thus  the  cable  bus-message  switch  price  differential  is  signifi¬ 
cant  in  that  the  cable  bus  could  save  as  much  as  27  per  cent  over  a 
centralized  connection  architecture. 

When  reliability  issues  are  factored  into  the  cost  in  terms  of 
duplicating  message  switches  at  each  site  versus  duplicating  inter¬ 
face  units  to  critical  nodes  and  duplicating  cable  backbones,  the 
savings  almost  double: 


Cable  bus: 

(32  interface  units  and  two  backbones) 

Fixed  Cost  at  62,600  *  23  sites  =  $1,439,800 
Recurring  at  $15,600  *  23  sites  =$  358. 8QQ 

Total  $1,798,600 


Message  Switch: 

(2  message  switches  per  site) 

Fixed  Cost  at  $10 3,108*23  sites  = 

Recurring  at  56,460  *  23  sites  = 

Total 

In  this  case,  the  cable  bus  would  save  almost  51  per  cent. 

4.5  Flexibility 

A  cable  bus  is  an  extremely  flexible  system.  A  message  switch 
is  a  relatively  fixed  architecture.  The  physical  modularity  of  the 
interface  units  is  the  key  to  cable  bus  flexibility.  This  physical 
modularity  makes  the  cable  bus  very  amenable  to  growth  or  shrinkage 
in  communication  requirements.  As  new  devices  are  added  to  the  cable 
bus,  interface  units  are  correspondingly  added  to  provide  incremental 
increases  in  buffering  capacity  and  protocol  processing  capabilities. 
NFE  incremental  increases  in  buffering  capacity  and  processing  capa¬ 
bility  tend  to  be  both  large  and  expensive.  This  physical  modularity 
also  has  the  advantage  that  new  device  types  may  be  interfaced  to  the 


2,271,484 
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cable  bus  without  affecting  the  operation  of  existing  software  in 
other  devices.  With  message  switch  architectures,  NFE  software  com¬ 
plexity  increases  non-linearly  with  the  addition  of  each  new  device 
type. 

The  degree  of  software  complexity  is  somewhat  smaller  in  inter¬ 
face  units  because  they  are  "closer"  to  the  interfaced  device. 
Assumptions,  untenable  in  the  message  switch,  can  be  made  based  on  a 
specific  "knowledge"  of  the  user  component  being  interfaced.  These 
simplifying  assumptions  lessen  the  amount  of  generality  and  defen¬ 
siveness  that  must  be  programmed  into  the  interface  unit  in  compari¬ 
son  to  the  kind  of  validity  checking  software  that  must  be  programmed 
into  the  message  switch. 
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5.0  DEVELOPMENT  ACTIVITY 

The  purpose  of  the  development  activity  was  to  provide  starting 
place  for  experimental  activity  performance  and  protocol  investiga¬ 
tions.  This  included  four  tasks: 

•  Installation  of  a  MITRE  Bedford  developed  cable  bus  system 
with  six  interface  units  in  the  MITRE  Washington  facility. 

•  Installation  of  a  cable  bus  gateway  minicomputer  to  the  ARPA 
network . 

•  Installation  of  an  initial  set  of  command  center  protocols  on 
an  LSI-11  cable  bus  host  and  the  PDP-11/70  gateway. 

•  Construction  of  medium  speed  interfaces  between  the  LSI-11 
and  the  cable  bus  and  the  PDP-11/70  and  the  cable  bus. 


The  resulting  test  bed  is  shown  in  Figure  14.  Each  of  the  tasks 
are  discussed  below. 

5.1  Cable  Installation 

The  cable  bus  consists  of  coaxial  cable,  amplifiers,  taps, 
splitters,  and  microprocessor-based  interface  units. 

The  coaxial  cable  was  installed  in  the  first  floor  and  basement 
levels  of  the  MITRE  Westgate  building.  The  total  length  of  the  cable 
is  approximately  3000  feet.  The  layout  of  the  cable  and  the  location 
of  splitters,  taps,  and  amplifiers  is  shown  in  Figure  15. 

System  integrity  was  verified  by  testing  cable  continuity  to 
detect  broken  or  missing  connections.  This  was  followed  by  a  signal 
level  alignment  using  a  spectrum  analyzer  and  RF  signal  level  meter. 

Operational  integrity  was  verified  by  attaching  a  backboard 
interface  unit  and  a  tester  interface  unit  to  the  cable.  The  tester 
interface  unit  sent  a  continuous  stream  of  messages  to  the  backboard 
which  reflected  them  back  to  the  tester.  This  series  of  tests  veri¬ 
fied  that  system  delay  and  noise  were  within  specified  tolerances. 
Since  tester  software  may  be  temporarily  installed  in  any  interface 


FIGURE  15 

MITRE  WASHINGTON  LAYOUT 


unit,  these  tests  were  also  used  to  verify  the  correct  operation  of 
each  of  the  interface  units. 

5.2  Gateway  Installation 

A  PDP-11/70  minicomputer  system  was  used  as  a  gateway  between 
the  ARPA  network  and  the  cable  bus.  The  PDP-11/70  system  consists 
of: 

•  PDP-11/70  Central  Processor 

•  128K  words  of  main  memory 

•  67  Million  words  of  disk  storage 

•  9-track  tape  drive 

•  16-line  terminal  multiplexor  interface 

•  ARPA  network  interface  -  IMP11-A 

•  byte-at-a-time  DR11-C  interface 

The  UNIX  operating  system  was  installed  to  support  network  pro¬ 
tocol  software,  terminal  access  and  program  development. 

Finally,  to  provide  for  fine-grained  timings,  a  high-speed  pro¬ 
grammable  clock  was  installed.  Software  based  on  the  clock  was 
developed  to  enable  the  timestamping  of  messages  and  to  measure  the 
utilization  of  the  system  under  load  conditions. 

.3  Command  Center  Protocol  Installation 

The  Transmission  Control  Protocol  (TCP)  was  selected  as  an  ini¬ 
tial  baseline  to  support  internetting  between  the  cable  bus  and  the 
ARPA  network.  This  selection  was  made  for  several  reasons: 

•  The  TCP  meets  the  Command  Center  requirement  for  internetwork 
operations. 

•  TCP  meets  the  Command  Center  requirement  for  a  robust,  highly 
reliable  operation. 
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•  A  variant  of  TCP  is  being  used  for  the  DCA  Autodin  II  Net¬ 
work,  and  is  consequently  being  inplemented  in  the  WWMCCS 
Network  Front  End. 

•  TCP  has  been  adopted  as  a  Defense  Department  Standard. 

There  have  been  several  versions  of  TCP.  The  original  ideas 
were  published  in  1974,  and  the  first  specification,  now  known  as 
Version  1,  was  produced  later  that  year.  In  1976,  a  TCP  specifica¬ 
tion  was  produced  for  AUTCDIN  II.  In  connection  with  ARPA  internet¬ 
work  research,  the  original  Version  1  has  been  through  several  revi¬ 
sions,  resulting  in  Version  2  in  1977,  Version  3  in  1978  and  most 
recently  Version  4.  In  Version  4,^^  TCP  has  been  split  into  two 
distinct  protocols;  TCP  itself  and  a  lower-level  Internet  Protocol 
(IP).(18) 

TCP  manages  the  opening  and  closing  of  virtual  connections  via  a 
three-way  handshaking  procedure  and  provides  for  a  mechanism  whereby 
processes  exchange  letters  with  each  other.  Letters  may  be  broken  up 
into  segments.  The  basic  function  of  regulating  the  flow  of  segments 
between  processes  resides  in  the  TCP  module.  In  addition  to  flow 
control,  TCP  performs  sequencing,  duplicate  detection,  end-to-end 
acknowledgement  and  error  control  services. 

TCP  depends  upon  the  Internet  Protocol  to  handle  certain  func¬ 
tions  including  addressing,  fragmentation,  and  reassembly.  The  IP 
embeds  TCP  segments  into  Internet  segments.  The  Internet  Protocol 
handles  the  delivery  of  the  Internet  segments  from  source  to  destina¬ 
tion  through  a  system  of  interconnected  networks. 

To  construct  the  test-bed  as  expeditiously  as  possible,  existing 
inplementations  of  TCP  Version  4  and  the  Internet  protocol  were 
obtained  for  the  PDP-11/70  and  the  LSI-11.  The  PDP-11/70  TCP  and  IP 
were  obtained  from  Bolt  Beranek  and  Newman,  Incorporated  which  had 
inplemented  TCP  and  IP  as  part  of  the  Exploratory  Data  Network  (EDN) 
for  DCA.  The  LSI-11  TCP  and  IP  implementations  for  the  MOS  operating 


system  were  obtained  from  the  Stanford  Research  Institute  which  is 
developing  a  microprocessor-based  network  access  host  as  part  of  an 
ARPA  Packet  Radio  networking  project.  The  initial  layering  of  proto¬ 
cols  for  the  test-bed  cable  bus  system  was  shown  in  Figure  4. 

5.4  PDP-11/LSI-11  Cable  Interfaces 

The  cable  bus  interface  units  were  originally  constructed  to 
support  RS-232C  terminal  access  to  the  cable  bus.  RS-232C  restricts 
data  transfer  speed  between  the  interface  unit  and  the  user  device  to 
19. 2K  bps. 

To  support  realistic  cable  bus  computer- to-computer  data 
transfer  speeds  a  higher  speed  interface  was  required.  The  RS-232C 
interfaces  were  replaced  in  two  interface  units  with  faster  8-bit 
parallel  interfaces.  The  parallel  interfaces  have  a  theoretical  max¬ 
imum  operating  speed  of  200K  bps.  Since  the  transfer  speed  of  the 
cable  is  307. 2K  bps,  this  speed  was  thought  to  be  sufficient  to  sup¬ 
port  experimental  measurements. 

The  parallel  interfaces  also  had  the  secondary  benefit  of  pro¬ 
viding  control  handshaking  signals  to  govern  the  flow  of  data  between 
the  interface  units  and  the  host  computers.  These  handshaking  sig¬ 
nals  provided  a  rudimentary  form  of  flow  control  needed  to  keep  one 
side  of  the  interface  from  sending  data  too  fast  for  the  other  side 
to  receive. 


6.0  EXPERIMENTAL  ACTIVITY 


The  purpose  of  the  experimental  activity  was  to  use  the  test  bed 
facility  to  gain  hands-on  insight  into  the  existing  capabilities  and 
performance  of  the  MITRE  cable  bus  system  and  to  evolve  a  set  of  pro¬ 
tocols  to  support  command  center  communication  requirements. 

Four  experiments  were  performed.  The  first  experiment  met  a 
need  to  determine  the  effective  throughput  and  bandwidth  of  the  cable 
bus  backbone.  The  second  experiment  measured  the  throughput  and 
bandwidth  of  a  virtual  circuit  loop  implemented  by  user  processes  and 
TCPs  on  the  PDP-11/70  and  LSI-11.  The  results  of  this  experiment 
served  as  a  catalyst  which  lead  to  the  restructuring  of  the  mechan¬ 
isms  within  the  initial  protocol  layering.  The  third  experiment 
measured  the  throughput  and  bandwidth  of  the  new  restructured  proto¬ 
col  inplementations.  The  fourth  experiment  verified  the  capability 
of  the  restructured  protocol  to  interface  with  the  ARPA  network  pro¬ 
tocols. 

6.1  Experiment  1:  Cable  bus  £ack&>ng i’.erf  ormance 

This  experiment  met  a  need  to  determine  the  effective  throughput 
of  the  backbone  cable  bus  system  by  measuring  the  maximum  number  of 
messages  per  second  processed  by  an  interface  unit  and  the  effective 
bandwidth  of  the  backbone  cable  bus  system  by  measuring  the  maximum 
number  of  bits  per  second  transferred  through  the  cable  bus. 

The  experiment,  shown  pictorial ly  in  Figure  16  below,  relied  on 
placing  the  value  of  a  100K  Hz  clock  (timestamping)  in  an  outgoing 
stream  of  messages  from  the  PDP-11/70  to  a  backboard  interface  unit 
which  "reflected"  each  message  back  to  the  PDP-11/70  where  it  was 
again  timestamped.  Timestamping  took  place  at  the  very  lowest  levels 
of  the  PDP-11/70  operating  system  softwares  so  as  to  eliminate  the 
effect  of  operating  system  performance  on  the  measurements.  The  out¬ 
going  and  incoming  timestamps  were  compared  to  synthesize  a  round- 
trip  measurement. 
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0  -  TIMESTAMP 


•  Throughput  -  337  MSGS/SEC 

•  Bandwidth  -  36K  BPS 

•  Poor  Performance 

-  Older  Slow  BIUS  -  MOS  6502 

-  Chatacter-at-a-time  Interface 

-  Small  Maximum  Packet  Size 


FIGURE  16 

CABLE  BUS  BACKBONE  EXPERIMENT 
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The  message  size  was  varied  in  order  to  measure  throughput  and 
bandwidth.  The  sizes  of  the  messages  were  set  at  the  smallest  length 
possible  (12  bytes)  to  measure  throughput  and  set  to  the  largest  pos¬ 
sible  (128  bytes)  to  measure  bandwidth.  The  throughput  was  measured 
at  337  message  per  second.  This  throughput  is  rated  as  acceptable. 
The  bandwidth  was  measured  at  36K  bps.  This  is  rated  as  poor  perfor¬ 
mance. 

The  performance  was  primarily  limited  by  the  speed  of  the  micro¬ 
processor,  the  inter rupt-per-character  PDP-11/70  interface  unit 
interface,  and  the  small  maximum  packet  size  (128  bytes/packet) .  All 
of  these  factors  will  be  inproved  in  newer  versions  of  the  interface 
unit.  These  results  graphically  demonstrate  that  cable  bus  systens 
in  their  present  state  of  development  will  not  support  command  center 
requirements. 

Experiment  1  was  performed  with  no  background  traffic  on  the 
cable  bus.  To  determine  the  degradation  in  message  flow  induced  by 
background  traffic,  a  traffic  generator  interface  unit  was  added  to 
the  experiment.  The  traffic  generator  interface  unit  simply  sent  a 
continuous,  uncontrolled  stream  of  messages  to  the  backboard  inter¬ 
face  unit  and  ignored  messages  received  from  the  backboard.’  Tlie 
traffic  generator  was  allowed  to  consume  as  much  of  the  cable  bus 
resources  as  it  could,  but  it  was  not  capable  of  saturating  the  cable 
bus.  The  experiment,  shown  in  Figure  17,  resulted  in  no  significant 
changes  in  the  previous  throughput  or  bandwidth  measurements. 

6.2  Experiment  2;  Standard  TCP  Perf.ocroange 

Given  that  the  first  experiment  provided  a  measurement  of  the 
basic  speed  of  the  cable  bus  backbone,  it  was  of  interest  to  measure 
the  throughput  and  bandwidth  of  TCP-based  communications  over  the 
cable.  To  do  this,  the  second  experiment  expanded  on  the  concept  of 
timestamping  minimum  and  maximum  sized  messages  in  transit  around  a 
loop.  The  loop,  shown  in  Figure  18,  was  comprised  of  four  processes: 


11/70 


LSI-11 


•  Unix  TCP-4  slow  -  6.4K  bps 

Unix  Ipc 

TCP  -  Device  Driver  Interface 
Character-at-a-time 

•  MOS  TCP-4  Respectable  -  25K  bps 


FIGURE  18 

TCP  CABLE  BUS  EXPERIMENT 


two  located  in  the  PDP-11/70  and  two  located  in  the  LSI-11.  Each 
message  was  timestamped  at  ten  locations  spaced  unevenly  around  the 
loop.  The  reason  for  the  asymmetry  of  the  timestamp  locations  was 
based  on  the  difference  in  the  available  timestamp  clock  rates 
between  the  PDP-11/70  (100K  Hz)  and  the  LSI-11  (60  Hz).  The  LSI-11 
clock  is  so  slow  that  meaningful  timestamp  values  are  not  obtained 
unless  the  timestamp  locations  are  spaced  far  enough  apart  to  let  the 
clock  "tick". 

The  table  below  describes  the  location  of  each  timestamp. 
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1  Message  generated 

2  Message  received  from  the  MSG  Generator 

3  Message  given  to  cable  device  driver  for  transmission 

4  Message  received  from  the  cable 

5  Message  received  from  LSI-11  TCP 

6  Message  sent  to  LSI-11  TCP 

7  Message  transmitted  to  cable 

8  Message  received  from  cable  device  drivers 

9  Message  transmitted  to  user 

10  Message  received  from  PDP-1/70  TCP 

By  comparing  the  timestamp  values  of  different  timestamp  loca¬ 
tions,  one  can  get  an  indication  of  the  overall  bandwidth  and 
throughput  as  well  as  a  detailed  breakdown  on  where  that  time  is 
being  spent. 

The  results  of  this  experiment  are  summarized  in  Table  III. 
Considering  the  36K  bps  speed  of  the  communications  backbone,  the 
25K  bps  throughput  of  the  LSI-11  system  is  respectable.  However,  the 
6.4K  bps  speed  of  the  PDP-11/70  TCP  is  poor.  This  poor  performance 
is  due  to  11/70  TCP  implementation  and  TCP  protocol  overhead  factors. 

6.2.1  TCP  Implementation 

The  TCP  impl orientation  on  the  PDP-11/70  makes  heavy  use  of  UNIX 
inter-process  communication  primitives,  UNIX  pipes.  Use  of  these 
primitives  represents  almost  one-third  of  the  total  packet 
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TCP  PERFORMANCE  MEASUREMENTS 
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EXPERIMENT  2  RESULTS 


0  -  lOK  SAMPLE  PACKETS 


AVERAGE  TIME  BETWEEN  POINTS 


1-2 

2-3 


HSBCS/BKTE 

5.602 

3.697 


4- 5 

5- 6 

6- 7 


0.628 

0.000 

0.613 


8- 9  0.105 

9- 10  0.487 


L  FLOW  RATE  MSBC/BYTE 

11/70  2.472 

LSI-11  0.621 


MSGS/SEE _ BPS  ( XN/QUT1 

3.16  6472  (3236/3236) 

12.58  25K(12.5K/12.5K) 
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transmission  time.  This  time  is  almost  equal  to  the  amount  of  time 
spent  sending  a  packet  to  the  cable,  looping  it  through  the  LSI-11 
TCP  and  user  process  and  receiving  it  again  by  the  11/70  TCP.  Con¬ 
sidering  that  the  11/70  processor  is  ten  times  faster  than  the  LSI- 
11,  there  is  clearly  room  for  improvement.  An  effort  of  several 
months  would  be  required  to  change  the  basic  transport  architectures 
of  the  UNIX  pipe  mechanism.  An  unscheduled  task  of  this  magnitude 
was  not  possible  given  the  available  resources  in  FY  79. 

6.2.2  TCP  Protocol  Overhead 

The  amount  of  per-message  overhead  required  to  transfer  a  mes¬ 
sage  was  the  second  major  cause  of  the  poor  throughput.  A  message, 
as  shown  in  Figure  19,  requires  8  bytes  of  local  cable  bus  header,  20 
bytes  of  Internet  protocol  overhead,  and  20  bytes  of  TCP  protocol 
overhead.  This  means  that  each  full  message  (maximum  size  128  bytes) 
is  composed  of  50  bytes  of  header  and  78  bytes  of  data.  Thus  39  per 
cent  of  each  messager  is  header.  This  is  significant  when  compared 
with  ARPA  network  overheads  of  0.8  per  cent  per  maximum  size  message. 
This  overhead  can  be  reduced  in  two  ways:  1)  by  increasing  the  max¬ 
imum  size  of  the  message,  and  2)  by  decreasing  the  number  of  overhead 
bytes . 

Increasing  the  maximum  message  size  requires  an  increase  in  the 
buffering  capacity  of  the  interface  unit  and/or  an  increase  in  the 
basic  transfer  speed  of  the  coaxial  cable.  Increased  buffer  capacity 
is  a  matter  of  enlarging  the  memory  in  the  interface  unit.  Increas¬ 
ing  the  cable  transfer  speed  requires  a  modification  to  the  interface 
unit  modem  and  an  increase  in  the  basic  operating  speed  of  the  inter¬ 
face  unit  microprocessor.  Thus,  increasing  the  maximum  message  size 
requires  a  moderate  amount  of  work.  Unfortunately,  time  and  person¬ 
nel  constraints  prevented  work  in  this  area. 

Reducing  per  message  overhead  by  decreasing  the  number  of  over¬ 
head  bytes  is  somewhat  sinpler.  The  reductions  lead  to  the  protocol 
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8  Source  Destination  j  Seq  Type  Rseq  Length  Cable 


ersion  IHL 


Identification 


Protocol 


Total  Length 


Flags  Fragment  Offset 


Header  Checksum 


Source  Address 


Destination  Address 


Source  Port 


Destination  Port 


Sequence  Number 


Acknowledgment  Number 


Offset  Reserved  Flags 


Checksum 


Window 


Urgent  Pointer 


architecture  described  in  Section  7.  The  resulting  message  fc 
served  as  a  basis  for  Experiment  3. 


6.3  Experiment  3:  Modified  TCP  Performance 

Experiment  3  was  a  repetition  of  Experiment  2  as  shown  in  Fi 
20,  with  the  message  format  shown  in  Figure  21.  The  purpose  of 
experiment  was  to  insure  that  no  significant  increases  in  per-mes 
processing  time  had  been  introduced  by  the  reprogramming  effort, 
results  of  the  experiment  are  summarized  in  Table  IV  below, 
decrease  in  header  size  resulted  in  an  expected  coriespon 
increase  in  the  bandwidth  of  the  PDP-11/70  (from  6.4K  bps 
8.3K  bps)  and  LSI-11  (from  25K  bps  to  28. 9K  bps) . 

6.4  Message  Switch  -  Cable  Bus  Performance  Comparison 

At  present,  the  test  bed  cable  bus  performance  compares  unfa 
ably  to  the  message  switch.  This  is  due  to  the  fact  that  both 
message  switch  and  the  cable  bus  do  not  accurately  represent  the 
formance  capabilities  of  the  cable  bus  and  the  Network  Front 
architectures.  Nevertheless,  the  performance  measurements  are 
indication  of  what  exists  today. 

NFE  performance  measurements  were  made  for  an  early  version 

the  NFE  called  the  Experimental  Network  Front  End  (ENFE) .  T 

measurements  were  used  in  comparisons  with  the  cable  bus.  Per 

mance  measurements  of  a  newer  version  of  the  Nmn,  called  the  Int 

Network  Front  End  were  not  available.  Doth  the  Interim  and  Exp 

mental  Network  Front  End  versions  are  supported  by  a  general  pur 

operating  system,  UNIX.  The  general  purpose  nature  of  UNIX  seve 

limits  data  communications  throughput.  A  new  operating  system 

under  construct 'on  may  increase  NFE  throughput  by  as  much  as  a  fa- 

(19) 

of  three  to  five  (for  a  non-secure  version). 

The  NFE  performance  measurements  are  described  in  detail  in 
et  al . ^  In  that  report,  the  NFE  was  measured  as  havin 


•  Unix  TCP-4  slow  -  8.3K  bps 

Unix  Ipc 

TCP  -  Device  Driver  Interface 
Character-at-a-time 

•  MOS  TCP-4  Respectable  -  28. 9K  bps 


FIGURE  20 

MODIFIED  TCP  CABLE  BUS  EXPERIMENT 
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Destination  Host 


Source  Port 


Destination  Port 


Packet  Acknowledgment 
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Control 


FIGURE  21 

MODIFIED  CABLE  BUS  TCP  HEADER 
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TABLE  I V 

MODIFIED  TCP  PERFORMANCE  MEASUREMENTS 
EXPERIMENT  3  RESULTS 


0  -  10K  SAMPLE  PACKETS 


AVERAGE  TIME  BEflWEEN  POINTS _ MSECS/BXIE 

1- 2  3.774 

2- 3  2.970 

4- 5  0.568 

5- 6  0.000 

6- 7  0.537 

8- 9  0.176 

9- 10  0.558 


AVG.  FI&PAXS _ MSEE/EXTE 

11/70  1.869 

LSI-11  0.552 


MSGS/SEC  BPSUN/QUrl 
4.18  8360  (4280/4280) 

14.13  28.9K(14.47K/14.47K) 
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average  maximum  bandwidth  of  33. 5K  bps.  If  the  highest  throughput 
from  Experiment  3  (28. 9K  bps)  is  compared  to  the  average  NFE  measure¬ 
ment  (33. 5K  bps)  a  differential  of  approximately  14  per  cent  results. 

Currently,  the  test  bed  cable  bus  system  is  supported  by  older 
8-bit  microprocessors.  The  processor  clock  rate  is  slow,  2  MHz.  The 
instruction  set  of  the  microprocessor  is  rudimentary,  requiring  a 
number  of  instructions  to  perform  meaningful  operations.  Newer 
microprocessors  have  clock  rates  that  are  twice  as  fast  as  existing 
interface  unit  clock  rates.  These  new  microprocessors  also  have  more 
efficient  instruction  sets.  Microprocessors,  which  will  be  available 
within  the  year,  are  purported  to  operate  at  ten  times  the  speed  of 
their  older  counterparts. 

The  test  bed  hardware  interfaces  are  also  rudimentary,  requiring 
an  interrupt  to  handle  each  character  received  or  transmitted.  Fas¬ 
ter  direct  memory  access  interfaces  will  significantly  decrease  the 
interrupt  overhead,  thereby  increasing  the  transfer  speed  between  the 
interface  units  and  the  test  bed  computers. 

Present  measurements  show  that  the  test-bed  system  is  14  per 
cent  slower  than  the  ENFE.  It  is  felt  that  this  relationship  will 
change  with  the  advent  of  new  cable  bus  interface  units  and  a'  new 
operating  system  for  the  NFE. 

If  the  new  NFE  operating  system  performs  as  expected,  a  three  to 
five  fold  increase  in  NFE  performance  may  be  forthcoming.  Thus  an 
NFE  performance  estimate  of  100. 5K  bps  to  167. 5K  bps  might  be 
expected. 

During  FY  80  a  new  cable  bus  interface  unit  based  on  a  fast  16- 
bit  microprocessor  (Zilog  8000)  will  be  tested.  This  microprocessor 
is  purported  to  be  ten  times  faster  than  the  existing  interface  unit 
microprocessor.  Furthermore,  the  instruction  set  of  the  new  micro¬ 
processor  is  more  efficient,  allowing  more  meaningful  functions  to  be 
performed  with  fewer  instruction  fetch  cycles.  It  is  expected  that 
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the  combination  of  this  new  microprocessor  and  direct  memory  access 
I/O  will  massively  increase  cable  bus  performance.  Speculative  esti¬ 
mates  are  that  an  increase  of  from  five  to  ten  fold  in  performance 
may  be  realized. 

Since  each  interface  unit  is  capable  of  this  increased  perfor¬ 
mance,  the  overall  performance  of  the  cable  bus  becomes  a  function  of 
the  number  of  active  interface  units.  Each  interface  unit  then  may 
be  capable  of  from  144. 5K  bps  to  289K  bps.  If  four  interface  units 
are  active,  578K  bps  to  1156K  bps  may  be  measured.  Thus,  four  inter¬ 
face  units  are  a  minimal  number  to  support  an  acceptable  traffic  rate 
if  all  four  operate  at  maximum  capacity.  In  an  operational  installa¬ 
tion,  several  more  interface  units  operating  at  only  fractional  capa¬ 
cities  might  be  better  suited  to  the  application,  but  acceptable 
traffic  flows  will  easily  be  maintained. 

The  relative  performance  of  the  NFE  and  the  cable  bus  then  are 
seen  as  changing  to  a  point  where  the  cable  bus  will  be  significantly 
faster  than  the  message  switch.  FY  80  measurements  will  support  a 
less  speculative  comparison. 

6.5  Experiment  4:  Interneting  Experiment 

The  fourth  experiment  verified  the  capability  of  the  newly 
evolved  protocol  tested  in  Experiment  3  to  function  in  an  internet 
environment  with  long-haul  networks,  specifically  the  ARPA  network. 

The  verification  was  in  the  form  of  opening  a  series  of  connec¬ 
tions  between  the  LSI-11  and  various  ARPA  network  sites  via  11/70 
based  gateway  translation  software.  The  expeiment  is  shown  pictori¬ 
al  ly  in  Figure  22  below.  The  translation  software,  in  the  form  of  a 
modified  cable  bus  TCP  implementation,  took  "open-virtual-circuit" 
requests  and  translated  them  into  ARPA  network  TCP  "open-virtual- 
circuit"  requests  and  standard  ARPA  network  Host-to-Host  "open- 
virtuai-circuit"  requests.  Once  the  connection  was  open,  a  process 


DISTANT 

HOST 


11/70 

GATEWAY 


LSI-11 


CABLENET 


FIGURE  22 

INTERNETTING  EXPERIMENT 
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was  started  to  transfer  data  between  the  ARPA  network  and  the  cable 
bus  network. 

Telnet  connections  were  completed  to  various  ARPA  network  hosts 
using  the  Host-to-Host  translation  software.  A  TCP  loop  was  made 
through  the  ARPA  TCP  and  back  into  the  LSI-11.  On  the  whole,  the 
translation  software  was  reasonably  easy  to  construct  and  was  put 
together  quickly.  However,  there  are  significant  problems  such  as 
exception  condition  and  out-of-band  signal  handling  which  need  to  be 
factored  into  the  translation  handling  software.  These  problems  will 
be  attacked  during  the  coming  fiscal  year. 


7.0  EVOLVED  PROTOCOL  ARCHITECTURE 


The  next  generation  WWMCCS  functional  requirements  and  the  cable 
bus  characteristics,  coupled  with  our  early  experimental  findings, 
and  our  view  of  the  future  microprocessor  interface  unit,  dictated 
the  necessity  for  a  WWMCCS  protocol  architecture.  Our  intention  was 
to  construct  a  protocol  architecture  to  fit  these  requirements  and 
still  remain  open  enough  to  evolve  nicely  to  the  large  number  of  per¬ 
ceived  command  center  applications.  Our  approach  has  been  to  provide 
a  good  set  of  established  protocol  mechanisms  within  an  extensible 
structure  such  that  protocols  may  evolve  on  a  stepwise  basis  as  new 
protocol  mechanisms  and  command  center  applications  arise.  In  addi¬ 
tion,  the  design  of  this  protocol  architecture  does  not  preclude  the 
transparent  transport  of  other  existing  protocols  such  as  TCP. 

The  protocol  architecture  is  also  based  on  the  idea  that  there 
are  really  very  few  new  protocols.  Most  new  protocols  are  recombina¬ 
tions  or  reformattings  of  such  functions  as  opening  a  virtual  connec¬ 
tion  or  flow  controlling  data  as  it  passes  over  a  virtual  connection. 

The  protocol  architecture  that  results  from  this  point  of  view 
is  shown  in  Figure  23. 

•  Level  0  provides  the  cable  bus  contention  mechanism.  This 
level  decides  when  a  packet  should  be  transmitted  to  the 
cable  and  handles  packet  collisions. 

•  Level  1  provides  a  flexibly  structured  set  of  protocol 
mechanisms  which  in  combination  provide  protocol  capabilities 
ranging  from  raw,  unsequenced,  unreliable  datagrams  to  a 
fully  sequenced,  reliable  data  stream.  This  layer  (the  flex¬ 
ible  transport)  is  described  in  detail  below. 

•  Level  2  represents  a  series  of  protocol  inplementations  which 
are  constructed  by  combining  level  1  mechanisms.  Note  that  a 
Transmission  Control  Protocol  (TCP)  implementation  rests  com¬ 
fortably  at  this  layer  by  using  only  a  very  few  of  the  level 
1  mechanisms.  The  datagram  inplementation  provides  a  user 
interface  to  the  level  1  address  mechanisms  and  adds  the 
capability  to  perform  fragmentation  and  reassembly  of  larger 
sized  datagrams.  The  connection  management  inplementation 
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provides  management  of  virtual  circuit  connections  using  a 

timer  based  protocol  described  in  Fletcher  and  Watson. 

The  data  stream  implementation  provides  a  user  interface  to 
the  reliable,  sequencing  and  out-of-band  signaling  mechanisms 
of  level  1  to  form  a  reliable,  sequenced  data  stream  capabil¬ 
ity. 

•  Level  3  represents  examples  of  higher  level  protocols  which 
make  use  of  the  functions  provided  by  layers  1  and  2. 


Thus  level  2  software  may  exist  as  a  simple  combination  of  level 
1  mechanisms  providing  an  interface  to  the  next  higher  level  or  it 
may  implement  a  full  set  of  its  own  mechanisms  using  few  of  the  level 
1  mecnanisms. 

The  name  server  implementation  provides  a  mapping  between  string 
names  of  objects  and  internetwork  addresses  described  in  Postel.^D 

The  broadcast  implementation  provides  a  capability  to  group  a 
set  of  users  into  a  conversation  such  that  a  message  generated  by  one 
user  is  received  by  all  users. 

File  Access  provides  access  to  remote  file  data.  The  File  Access 
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implementation,  based  on  a  protocol  suggested  by  Day,'  '  allow  data 
transfers  to  be  described  as  a  series  of  file  byte  pointer  and  length 
requests  followed  by  data  responses. 

The  virtual  terminal  implementation  maps  terminal  characteris¬ 
tics  into  standard  virtual  terminal  representations.  It  includes 
graphics  functions  such  as  line,  curve,  and  shaded  polygon  drawing  as 
well  as  the  more  mundane  record  mode,  stream  mode,  and  terminal 
option  negotiation. 

7.1  Flexible  Transport  Protocol 

(23) 

The  Flexible  Transport  Protocol  defines  a  set  of  rules  to 
govern  the  transport  of  blocks  of  data  over  interconnected  cable  bus 
networks  with  binary  degrees  of  reliablity,  flow  control,  addressing, 
and  other  common  end-to-end  and  transport  level  mechanisms.  These 


mechanisms  are  grouped  at  this  level  to  allow  the  optional  specifica¬ 
tion  of  each  of  the  mechanisms  in  terms  of  its  effect  on  the  format 
of  the  ^suiting  protocol  header.  Each  header  contains  a  "bit-map" 
specifying  the  "shape"  or  attributes  of  the  remaining  portion  of  the 
packet.  These  attributes  are  groups  of  data  fields  which,  if  speci¬ 
fied,  cause  the  protocol  mechanisms  referred  to  above  to  be  invoked. 
If  an  attribute  is  not  specified,  default  processing  mechanisms,  such 
as  always  accepting  a  packet  as  in  sequence  if  the  sequence  attribute 
is  not  specified,  are  invoked.  The  obvious  advantage  of  this  scheme 
is  that  if  a  mechanism  is  not  required  to  support  a  particular  type 
of  data  transfer  no  price  is  paid  in  terms  of  header  overhead  and 
processing  cycles. 

If  in  the  future  a  general  environment  exists  where  the  overall 
packet  length  is  not  restricted,  the  flexible  header  scheme  may 
easily  evolve  into  a  fixed  scheme.  We  should  also  note  that  in  prac¬ 
tice,  we  don't  envision  the  header  length  changing  from  packet  to 
packet,  but  rather  for  the  attribute  specification  to  be  a  function 
of  the  application  process. 

The  Flexible  Transport  Protocol  supports  the  following  mechan¬ 
isms: 

Packet  Assembly, 'Disassembly.  This  mechanism  provides  packet 
formatting  far  out-going  packets  from  a  global  set  of  vari¬ 
ables  and  a  specification  of  attributes  to  be  applied  to  any 
packet  data.  It  also  provides  for  the  disassembly  of 
received  packets  and  the  passing  of  any  packet  attributes  and 
data  to  a  pre-def ined  sequence  of  mechanisms  within  the  flex¬ 
ible  transport  layer. 

Packet  Addressing.  This  mechanism  provides  for  the  detection 
of  packets  addressed  to  the  local  host.  It  detects  packets 
addressed  to  a  remote  network  if  the  local  host  is  a  gateway 
to  that  network.  It  detects  packets  addressed  to  the  local 
host.  It  locates  local  pxart  data  structures.  It  also  han¬ 
dles  broadcast  messages  should  any  of  the  destination  host  or 
port  attributes  of  the  packet  Lx?  absent. 
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Packet  Typing.  The  packet  typing  mechanism  provides  for  the 
manipulation  of  a  registered  set  of  packet  types  which 
include  host  reset  requests,  protocol  error  messages,  and 
host  status  messages. 

Packet  Sequencing.  The  packet  sequencing  mechanism  provides 
a  means  for  identifying  whether  a  packet  is  in  sequence,  out 
of  sequence,  or  a  duplicate. 

Flow  Control.  The  flow  control  mechanism  provides  a  sliding 
window  describing  a  range  of  acceptable  sequence  numbered 
packets.  It  also  provides  for  the  acknowledgement  of  previ¬ 
ously  received  packets. 

Out  of  Band  Signal.  The  out  of  band  signal  mechanism  pro¬ 
vides  a  means  of  specifying  a  location  in  the  data  stream 
where  "interesting"  information  resides. 

Figure  24  illustrates  the  hierarchical  structure  of  the  flexible 
transport  attributes.  Flow  control,  for  example,  makes  use  of  the 
packet  sequencing,  and  out  of  band  signaling  needs  to  be  free  of  flow 
control  constraints.  Packet  assembly/disassembly  is  of  course  always 
needed,  and  one  can  select  any  combination  of  the  other  mechanisms. 
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8.0  CONCLUSION 

Based  on  the  analysis  activity,  it  appears  that  the  cable  bus 
will  be  as  secure  as  the  message  switch,  from  27  per  cent  to  51  per 
cent  less  expensive,  significantly  more  reliable,  and  have  better 
overall  performance  with  a  flexibility  for  incremental  growth  sur¬ 
passing  the  message  switch  architecture.  However,  due  to  the  early 
stages  of  development  of  both  the  cable  bus  and  the  message  switch, 
conclusive  opinions  as  to  their  applicability  to  the  command  center 
are  necessarily  subjective.  FY  80  cable  bus  protocol  development  and 
testing  should  enable  less  subjective  comparisons. 

Hie  FY  80  experimental  cycle  will  insure  the  soundness  of  the 
implementation  of  the  protocol  architecture  described  in  Section  7. 
Hie  protocol  implementation  will  be  expanded  to  include  a  virtual 
terminal  protocol  with  color  graphics  capabilities.  It  is  planned 
that  a  cable  bus  system  will  be  installed  at  DCA  Reston  in  order  to 
begin  evaluating  the  system  in  a  command  center  setting.  In  a 
related  MITRE  internal  research  and  development  effort,  a  new,  faster 
interface  unit  will  be  developed  and  tested. 
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